Tableau Public Authoring MCP

by andyyaro

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
Disambiguation5/5
Each tool has a clearly distinct purpose: capabilities, templates, validation, building, inspection, app status, opening, in-app validation, publishing, and verification. No two tools overlap in function, and descriptions clearly differentiate them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_authoring_capabilities, build_workbook, publish_to_tableau_public). No mixing of conventions, and verbs clearly indicate the action.
Tool Count5/5
Ten tools is well-scoped for the domain of authoring and publishing Tableau Public workbooks. Each tool serves a necessary step in the workflow, from capability reporting to verification.
Completeness5/5
The tool set covers the full authoring and publishing lifecycle: capabilities, templates, dry-run validation, building, local inspection, app status, opening, in-app validation, publishing, and web verification. No obvious gaps for the stated purpose.
Average 3.7/5 across 10 of 10 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 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
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states it opens the workbook and detects error dialogs, but fails to disclose behavioral aspects such as whether the tool modifies the workbook, whether it requires user interaction, how long it takes, or what happens to the screenshot after capture. The lack of side-effect clarity (e.g., destructive hint) is a significant gap.
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 a single, front-loaded sentence that efficiently conveys the main purpose. However, it sacrifices necessary detail for brevity, leaving parameter semantics and usage unspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain 'Layer 3+4', what constitutes an error dialog, or how the screenshot is returned. The agent would need external context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (path, settle_s, screenshot_dir). The term 'settle_s' is ambiguous (likely a delay), and 'screenshot_dir' is not described. Without any clarification, the agent cannot correctly provide values.
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 specific purpose: 'Layer 3+4 validation: open the workbook in Tableau Public, detect error dialogs, and capture a screenshot proving rendered content.' It uses a specific verb (validate) and resource (workbook in Tableau Public), and distinguishes from related siblings like 'open_in_tableau_public' and 'verify_published_workbook' by defining its unique validation layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or how it differs from sibling validation tools like 'validate_workbook_spec' or 'verify_published_workbook'.
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?
States it is read-only, which is crucial for safety. However, with no annotations provided, the description should disclose more behavioral traits such as error handling, timeout behavior, or what constitutes a successful response. The current description is minimal.
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 extremely concise, using a single sentence. It is front-loaded with 'Layer 5 validation', which may be jargon, but overall the structure is efficient. Could be slightly improved by moving the important 'read-only' claim earlier.
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?
Given the tool's simplicity (one parameter, no output schema), the description covers the basic action but lacks completeness. It does not explain what 'confirms it responds' means (e.g., HTTP status 200) nor how the output signals success or failure. Also fails to differentiate from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'url' receives minimal additional meaning: it is described as a 'public Tableau URL'. With 0% schema description coverage, this is insufficient. The description should specify expected format (e.g., must start with 'https://public.tableau.com'), but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a public Tableau URL and confirms a response. It identifies the resource (public Tableau URL) and action (verify). However, it does not explicitly differentiate from sibling tools like validate_in_tableau_public, which may perform similar checks, and the jargon 'Layer 5 validation' is not explained.
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?
Implies usage for verifying a published workbook is accessible, but provides no guidance on when to use this tool over alternatives (e.g., validate_in_tableau_public). No exclusions or prerequisites are mentioned, leaving the agent to infer context.
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, the description must carry the full burden. It discloses that files are written to the spec's output directory and notes the determinism of .twb versus .twbx. However, it lacks details on authorization, overwrite behavior, error conditions, or prerequisites beyond the schema.
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 three sentences, front-loaded with 'PRIMARY TOOL', and every sentence provides essential information (purpose, output location, determinism). No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema and the absence of an output schema and annotations, the description is minimal. It does not explain return values, error handling, the build process, or prerequisites, leaving the agent with potential gaps for correct invocation.
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% with detailed descriptions for both parameters (spec and overwrite) and all nested properties. The tool description does not add additional meaning beyond what the schema already provides, so baseline 3 applies.
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 it is the 'PRIMARY TOOL' and specifies the action 'Compile a specification into .twb and .twbx with Hyper extracts'. It distinguishes itself from sibling tools like validation, inspection, and publishing by its primary build role.
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 labels the tool as 'PRIMARY' but does not provide explicit guidance on when to use it versus alternatives like validate_workbook_spec or inspect_local_workbook. No when-not-to or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only states 'Read-only' as behavioral info. No annotations exist, so description should disclose more (e.g., if requires auth, any side effects). Minimal for a no-annotation tool.
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?
Single sentence, no waste. Essential info is front-loaded. Efficient for a simple list tool.
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?
Describes output sufficiently for a parameterless list tool. Lacks mention of how output can be used with sibling tools (e.g., building a workbook), but given simplicity, adequate.
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?
No parameters, so schema coverage is 100%. Description adds context about return values (required shelves), which enhances understanding 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?
States exact action (list) and resource (supported worksheet templates) with output details (required shelves). Clearly distinguishes from sibling tools that validate, build, or publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or alternatives. With siblings like get_authoring_capabilities and validate_workbook_spec, the description provides no context for selection.
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?
Read-only behavior is mentioned, which is transparent given no annotations. However, the description does not elaborate on potential nuances like data freshness or permission requirements, 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?
Single sentence with no fluff, front-loaded with purpose. Every word contributes meaning.
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?
Adequate for a simple info tool, but lacks details on output format or the meaning of 'capabilities'. Given no output schema, more detail would improve completeness.
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 has zero parameters with 100% coverage, so description adds value by explaining the output categories. Baseline of 4 is appropriate as it compensates for lack of output 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?
Description clearly states the tool reports three specific categories: authoring capabilities, Tableau Public installation, and macOS permission state. Verb 'report' and resource are specific and distinct from sibling tools which focus on workbook operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'get_tableau_public_app_status'. The read-only nature is noted but not contextualized relative to sibling 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?
With no annotations, the description carries the burden and discloses key behaviors: no files written (dry run) and read-only. It also mentions returning actionable errors. This is sufficient for a validation tool, though it omits details on rate limits or performance.
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 zero waste. First sentence states the verb and resource; second adds key behavioral traits. Ideal conciseness.
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?
Adequate for a simple tool, but lacks detail on output format of 'actionable errors' and prerequisites (e.g., valid JSON schema). Could be more complete given the complex spec parameter.
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 embedded descriptions for the single parameter 'spec'. The tool description adds only the dry-run context, not parameter-specific meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates an authoring specification as a dry run, being read-only. It distinguishes from the build tool but does not explicitly differentiate from the sibling 'validate_in_tableau_public', which may also validate.
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 as a pre-build check (dry run) but provides no explicit guidance on when to use this versus alternatives like 'validate_in_tableau_public' 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, the description states safety and read-only nature but omits exactly what 'contents' means (e.g., file list vs metadata) and error behavior. Adequate but minimal.
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-load the purpose and behavior, with zero waste. Ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not explain the return format or data. For a read-only inspection tool, the output is a critical missing piece.
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 covers 100% of parameters with clear description ('Absolute .twbx path'). The tool description adds no extra parameter 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 identifies the resource (local .twbx archive) and action (inspect contents), with 'Read-only' distinguishing it from mutation tools like build_workbook or publish_to_tableau_public.
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?
'Safely inspect' and 'Read-only' imply usage for examining archives without modification. No explicit alternatives or exclusions, but the context from siblings makes the intended use clear.
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 does well to disclose key behaviors: it waits for the window and returns error verbatim. However, it does not explicitly state whether the tool modifies the workbook or the Tableau environment, though 'open' implies read-only. The waiting behavior is clearly 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?
The description is two sentences with no wasted words. It front-loads the main action and immediately provides additional context about waiting and error handling.
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?
For a tool with 2 parameters and no output schema, the description covers the essential behavior: opening a workbook, waiting for the window, and returning errors. It is slightly ambiguous about what happens on success (presumably returns nothing or success indicator), but overall adequate.
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 description adds no additional meaning to the parameters beyond what the input schema provides. The path parameter is already described as 'Absolute .twb or .twbx path' in the schema, and timeout_s has default/min/max bounds. The description's mention of 'Open a generated workbook' implicitly references the path but does not enhance parameter understanding.
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 ('open'), the resource ('generated workbook in Tableau Public'), and the specific behavior ('wait for its window', 'returns load error verbatim'). It distinguishes from sibling tools like 'publish_to_tableau_public' or 'validate_in_tableau_public' by focusing on opening and waiting.
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 the tool is for opening a generated workbook, but lacks explicit guidance on when to use it versus alternatives like 'validate_in_tableau_public' or 'publish_to_tableau_public'. No when-not or exclusions 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 provided, the description carries the full burden. It explicitly labels the action as 'DESTRUCTIVE / PUBLIC,' states 'Publication is irreversible and world-visible,' highlights the guard (confirm_publish=true), and discloses manual sign-in behavior. This is comprehensive, though it could mention error handling or failure modes.
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 two sentences: the first focuses on purpose and danger, the second on key details (irreversibility, guard, credential handling). No waste, front-loaded with the most critical 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?
For a destructive 9-parameter tool with no output schema, the description covers the essential aspects: irreversible publication, required guard, credential handling, and exact window name matching. It could mention return behavior or failure scenarios, but it is sufficiently complete for safe usage.
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 89%, so the schema already documents most parameters. The description adds little beyond what's in the schema (e.g., reiterates confirm_publish must be true and workbook_window exact matching). Baseline 3 is appropriate as it does not need to compensate.
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 starts with 'DESTRUCTIVE / PUBLIC. Publish an open workbook to the user's Tableau Public account...' and clearly distinguishes the tool from siblings like validate_workbook_spec or verify_published_workbook. The verb 'Publish' and resource 'open workbook to Tableau Public' are precise.
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 states 'Requires confirm_publish=true' and 'Never reads credentials; pauses for manual sign-in if required,' providing clear usage context. However, it does not explicitly state when not to use the tool or suggest alternatives among the sibling 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?
With no annotations, the description carries full responsibility. It explicitly states 'Read-only' and enumerates five specific aspects reported. It does not discuss prerequisites or error conditions, but for a status tool, this is sufficient.
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 a single sentence with front-loaded content. Every word adds value: 'Report', the list of items, and 'Read-only'. No redundancy or filler.
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, the description lists the reported items without specifying return format. This is adequate for an agent to understand what will be provided. Slightly incomplete as it doesn't mention failure modes or format, but acceptable for a status tool.
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?
There are no parameters, so schema coverage is 100% trivially. The description does not need to add parameter info. According to calibration, 0 parameters merits a baseline of 4.
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 'report' and specific resources: installation, version, running state, open windows, and Accessibility permission. It distinguishes from siblings by focusing on status information rather than authoring or publishing.
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 includes 'Read-only' which implies safe usage without side effects. While it does not explicitly list when to use vs alternatives, the context is clear among sibling tools. Slightly lacking explicit when-not or alternative references.
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:

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

Score Badge

Copy to your README.md:

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

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/andyyaro/tableau-public-authoring-mcp'

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