cwtwb is a Python-based MCP server for programmatically building, editing, validating, and migrating Tableau workbooks (.twb/.twbx) from code or agent tool calls (e.g., Claude, Cursor, VSCode).
Workbook Management
Create workbooks from templates or scratch, open existing ones, save as .twb or .twbx, and validate against the official Tableau XSD schema.
Worksheet Operations
List, add, clone, hide/unhide, caption, and refactor worksheets; list available datasource fields.
Chart Building
Configure bar, line, pie, map, KPI, text, and dual-axis charts with full control over rows, columns, marks, colors, labels, filters, tooltips, sorting, and axes. Apply styles and use preset chart recipes.
Data Connections
Set up Excel, Hyper, MySQL, or Tableau Server datasource connections.
Calculated Fields & Parameters
Add/remove calculated fields with custom formulas and add parameters with ranges and allowed values.
Dashboard Authoring
Combine worksheets into dashboards with layout control, add filter/highlight/URL actions, and generate layout JSON with ASCII preview.
Guided Authoring (Agentic Workflow)
Multi-stage pipeline: datasource intake → schema inspection → analysis brief → authoring contract → wireframes → execution plan → workbook generation, with human-in-the-loop confirmation at each stage.
Migration Tools
Profile a TWB, inspect a target schema, propose field mappings, preview and apply migration, or run a guided migration with blocker/warning detection.
Analysis & Capability Inspection
Analyze TWB files against cwtwb's capability registry, diff template gaps, and list/describe server capabilities.
Allows inspecting .hyper file schemas, resolving physical table names, and using Hyper as a datasource for guided workbook authoring.
The cwtwb package is distributed via PyPI for installation with pip.
The toolkit is a Python library and MCP server that allows programmatic generation of Tableau workbooks using Python code.
Provides XML engine (lxml) for patching, validating, and saving Tableau workbook XML files.
Tableau workbook engineering for reproducible
.twb/.twbxgeneration, validation, and migration.
cwtwb is a Python toolkit and Model Context Protocol (MCP) server for building Tableau Desktop workbooks from code or agent tool calls.
It is meant to be a workbook engineering layer, not a conversational analytics agent. The focus is reproducibility, inspectability, and safe automation in local workflows, scripts, and CI.
The agent design workflow and the design_advisor skill are informed by Adam
Mico's adammico-lab Tableau workflow skills,
especially Tableau Dashboard Blueprint's build-from-a-design-spec approach.
cwtwb independently adapts those ideas to reproducible .twb / .twbx
authoring; it does not depend on, bundle, or copy adammico-lab code or skill
content. cwtwb is not affiliated with Adam Mico, Salesforce, or Tableau.
The cw in cwtwb comes from Cooper Wenhua.
Author: Cooper Wenhua <imgwho@gmail.com>
Try the example workflow · Read the guide
Related MCP server: Tableau MCP
pip install cwtwbIf you want the bundled Hyper-backed example too:
pip install "cwtwb[examples]"If you want cloud validation (upload to Tableau Cloud/Server):
pip install "cwtwb[validate]"uvx cwtwbThe short form above remains the simplest option and is the default config shown in this repository. cwtwb is a smart entrypoint: with no arguments in an interactive terminal it prints CLI help; when launched by an MCP client over stdio it starts the server.
Add the server to your MCP client with the same command. For example:
{
"mcpServers": {
"cwtwb": {
"command": "uvx",
"args": ["cwtwb"]
}
}
}For Claude Code:
claude mcp add cwtwb -- uvx cwtwbFor VSCode, add cwtwb to your workspace or user mcp.json and use uvx cwtwb as the command.
If you prefer an explicit script name, these equivalent launch styles also work:
uvx cwtwb mcp
uvx --from cwtwb cwtwb-mcp
python -m cwtwb.mcp_serverThe same package also exposes first-class command-line workflows for humans, scripts, CI, and agents that need direct file operations instead of MCP tool calls.
cwtwb --help
cwtwb doctor
cwtwb status --json
cwtwb inspect workbook.twb --json
cwtwb validate workbook.twb
cwtwb analyze workbook.twb --json
cwtwb run examples/specs/basic_cli.yamlCommon write commands require an explicit output path by default:
cwtwb create --out output/base.twb
cwtwb chart add output/base.twb --worksheet "Sales by Category" --mark Bar --rows Category --columns "SUM(Sales)" --out output/chart.twb
cwtwb dashboard add output/chart.twb --name Overview --worksheets "Sales by Category" --out output/dashboard.twbUse --in-place only when you intentionally want to overwrite the input workbook, and --force only when replacing an existing output file.
convert detects TWB, TWBX, YAML, and JSON from file extensions. It does not
require Gallery, a template, or an active editor session:
cwtwb convert input.twbx --out workbook.yaml
cwtwb convert workbook.yaml --out workbook.json
cwtwb convert workbook.json --out rebuilt.twbx
cwtwb convert input.twbx --out unpacked.twbcwtwb export input.twb --out workbook.yaml is an alias. Native definitions
also work with cwtwb run workbook.yaml --out rebuilt.twb. Existing automation
specs keep their previous behavior. Outputs are not overwritten unless --force
is supplied; conversion never overwrites its input.
Python: from cwtwb import convert_workbook, then
convert_workbook("input.twbx", "workbook.yaml"). MCP exposes the same stateless
convert_workbook(input_path, output_path, force=False) tool.
The versioned cwtwb-native format currently represents the native XML tree:
document.root contains tag, attributes, text, ordered children, and
tail; comments, processing instructions, namespaces, thumbnails, and unknown
elements are retained. Edit formulas in calculation.attributes.formula and
layout geometry in zone attributes. XML attribute values remain strings. This
is a detailed structural format, not yet a simplified semantic workbook DSL;
no claim is made that every Tableau feature is understood or safely editable.
Conversion bypasses TWBEditor cleanup and does not inject generated comments.
XML declaration spelling, CDATA spelling, namespace prefixes, and ZIP metadata
are not promised byte-for-byte. Unknown nodes are retained, not interpreted.
Binary resources are copied to <output-name>.assets/, with relative paths and
SHA-256 hashes in the definition. Keep the definition and this directory together.
An unpacked TWB also has a <output-name>.resources.json companion to retain
unreferenced package assets for later repacking. File references are relocated
when needed; remote database connections remain remote. Standalone TWB discovery
currently covers Hyper/CSV/Excel connections and bitmap zones; arbitrary external
files referenced by custom extensions are not automatically discovered. TWBX
conversion retains every bundled resource file, including unknown extensions.
Missing known external resources produce warnings for text output and block TWBX packaging. Duplicate keys, unknown document properties/versions, missing or changed resource files, unsafe archive paths, multiple-TWB archives, and DTD-bearing XML fail explicitly. After deliberately changing an asset, update its recorded hash. Resource directories are not garbage-collected when outputs are replaced.
Conversion checks XML syntax and resource integrity, not Tableau calculations,
field-reference semantics, Desktop loading, rendering, or interactions. Use the
existing validation commands and Tableau runtime checks separately. run --validate
is intentionally rejected for native definitions rather than implying those checks
ran during conversion.
When cwtwb is connected as an MCP server, agents should call the exposed MCP tools directly through their client. They should not run shell commands such as mcp call cwtwb ..., mcp list-tools cwtwb, or gh api .../mcp/...; those commands are not part of cwtwb and are usually unavailable in normal Claude, Codex, Cursor, or VSCode environments.
If an agent cannot see tools such as create_workbook, add_worksheet, or save_workbook, restart or reconnect the MCP client and verify the server config. Clearing the uv cache only refreshes installed packages; it does not fix a stale client tool surface.
When using an existing .twb as a visual reference, agents must not copy Tableau XML column-instance tokens into chart inputs. Values such as [sum:Sales:qk], [none:Category:nk], [mn:Order Date:ok], or [federated.xxx].[sum:Profit:qk] are generated internals. Pass user-facing expressions such as Sales, SUM(Sales), Category, or MONTH(Order Date) instead.
Useful resources for agents:
cwtwb://tool-surface
cwtwb://skills/index
cwtwb://skills/data_quality
cwtwb://skills/design_advisor
cwtwb://skills/metric_blueprint
cwtwb://skills/dashboard_designer
cwtwb://skills/quality_review
cwtwb://skills/documentation
file://docs/tableau_all_functions.jsonCompatibility aliases are also available for common guessed URIs such as cwtwb://docs/manual-editing, but new prompts should prefer cwtwb://tool-surface and cwtwb://skills/index.
For client-specific details and the full reference, see https://github.com/aidatacooper/cwtwb/blob/main/docs/guide.md.
Custom dashboard layouts can now be authored as either JSON or YAML using the same declarative DSL. For agent workflows, generate a layout file first, then pass that file path into add_dashboard(layout=...).
generate_layout_json("output/layout.json", layout_tree, ascii_preview)
generate_layout_yaml("output/layout.yaml", layout_tree, ascii_preview)Both formats support the same wrapper structure:
layout_schema: canonical dashboard layout tree
_ascii_layout_preview: optional human/agent review aid
cwtwb includes seven packaged Gallery templates for common analytical structures. Recommendations use explicit requirements and return their scores, matching reasons, and penalties; they do not inspect data or silently generate charts.
from cwtwb import DashboardRequirements, recommend_gallery_templates
recommendations = recommend_gallery_templates(
DashboardRequirements(
primary_intent="trend",
has_temporal_data=True,
kpi_count=2,
chart_count=3,
chart_types=("Line", "Bar"),
)
)After calling list_worksheets, bind exact worksheet names with
materialize_gallery_layout(...) or the MCP generate_gallery_layout tool.
The generated result uses the same canonical DSL accepted by add_dashboard.
add_calculated_field checks identifiers used as function calls against the
packaged Tableau catalog before editing XML. For example, CHR(10) is rejected
with a CHAR() suggestion. This is a lightweight function-name check, not a
complete Tableau parser or substitute for Tableau Cloud semantic validation.
Use validate_formula=False only when targeting a newer Tableau function that
is not yet in the packaged catalog. Existing workbooks can be reviewed with
audit_calculated_fields(). Repairs are separate and default to dry_run=True.
Area | What you get |
Workbook authoring | Generate |
Chart building | Build bar, line, pie, map, KPI, dual-axis, layered, and ordered multi-column table workbooks |
Table calculations | Author calculation addressing metadata, domain completion, subtotals, and nested table-calculation dependencies |
Dashboard actions | Add filter, highlight, URL, navigation, parameter, and set actions through Python or MCP |
Safety | Validate function names and calculated-field roles, then validate structure, Tableau XSD (2026.1/2026.2), and REST API semantics before publishing |
Dashboard Gallery | Rank seven explainable layouts and bind exact worksheet names into the canonical DSL |
Cloud validation | REST API syntactic/semantic validation + upload to Tableau Cloud/Server with optional screenshot |
Migration | Repoint existing workbooks to new data sources with explicit steps |
MCP support | Drive workbook workflows from Claude, Cursor, VSCode, or other MCP clients |
This GIF shows the MCP tool flow that builds a dashboard step by step.
Interfaces
┌───────────────────────────────────────────────────────────────┐
│ ┌──────────────────────────┐ ┌───────────────────────────┐ │
│ │ MCP Server │ │ Python Library │ │
│ │ tools_workbook │ │ from cwtwb.twb_editor │ │
│ │ tools_validate │ │ import TWBEditor │ │
│ │ │ │ │ │
│ │ │ │ editor.add_...() │ │
│ │ │ │ editor.configure_...() │ │
│ │ │ │ editor.validate_schema() │ │
│ │ (Claude / Cursor / │ │ editor.save(...) │ │
│ │ VSCode / Claude Code) │ │ │ │
│ └─────────────┬────────────┘ └──────────────┬────────────┘ │
│ └──────────────┬────────────────┘ │
└───────────────────────────── ┼ ─────────────────────────────┘
▼
┌───────────────────────────────────────────────────────────────┐
│ TWBEditor │
│ ParametersMixin · ConnectionsMixin │
│ ChartsMixin · DashboardsMixin │
│ validate_schema() · save() │
└──────────┬──────────────────┬──────────────────┬─────────────┘
▼ ▼ ▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────────┐
│ Chart Builders │ │ Dashboard │ │ Analysis & │
│ │ │ System │ │ Migration │
│ Basic DualAxis │ │ │ │ │
│ Pie Text │ │ layouts │ │ migration.py │
│ Map Recipes │ │ actions │ │ twb_analyzer.py │
│ │ │ dependencies│ │ capability_registry │
└────────┬─────────┘ └──────┬───────┘ └──────────┬───────────┘
└───────────────────┼──────────────────────┘
▼
┌───────────────────────────────────────────────────────────────┐
│ Packaged References │
│ empty_template.twb · Superstore XLS/Hyper │
│ tableau_all_functions.json · dataset profiles │
│ vendored Tableau TWB XSD schemas (2026.1 / 2026.2) │
└───────────────────────────────┬───────────────────────────────┘
▼
┌───────────────────────────────────────────────────────────────┐
│ XML Engine (lxml) │
│ template.twb/.twbx → patch → validate → save │
└───────────────────────────────┬───────────────────────────────┘
▼
output.twb / output.twbx
▼
┌───────────────────────────────────────────────────────────────┐
│ Cloud Validation (optional) │
│ validate_workbook_api → REST API semantic validation │
│ upload_workbook → Tableau Cloud/Server publish │
│ screenshot_workbook → capture view for visual check │
└───────────────────────────────────────────────────────────────┘Mermaid view:
flowchart TD
subgraph Interfaces
MCP["MCP Server<br/>tools_workbook<br/>tools_validate"]
PY["Python Library<br/>TWBEditor API"]
end
subgraph Editor["Core Editor"]
TWB["TWBEditor<br/>parameters · connections<br/>charts · dashboards<br/>validate_schema · save"]
end
subgraph Builders["Workbook Systems"]
CHARTS["Chart Builders<br/>basic · dual-axis<br/>pie · text · map · recipes"]
DASH["Dashboard System<br/>layouts · actions<br/>dependencies"]
ANALYSIS["Analysis & Migration<br/>migration.py<br/>twb_analyzer.py<br/>capability_registry"]
end
subgraph References["Packaged References"]
REFS["empty_template.twb<br/>Superstore XLS/Hyper<br/>Tableau functions<br/>TWB XSD schemas"]
end
subgraph Engine["XML Engine"]
XML["lxml patch pipeline<br/>template.twb/.twbx → patch → validate → save"]
end
subgraph Outputs
OUT["output.twb / output.twbx"]
CLOUD["Cloud Validation<br/>REST semantic validation<br/>upload · screenshot"]
end
MCP --> TWB
PY --> TWB
TWB --> CHARTS
TWB --> DASH
TWB --> ANALYSIS
CHARTS --> XML
DASH --> XML
ANALYSIS --> XML
REFS --> TWB
REFS --> XML
XML --> OUT
OUT --> CLOUDThe reference layer is packaged with the library so agents and scripts can start from known-good workbook assets, resolve Tableau calculation syntax, run Hyper-backed examples, and validate against local XSD schemas without relying on a checked-out repository.
cwtwb is designed for tool-using agents, not just direct Python calls. The MCP server gives agents a small, stateful workbook editing surface; skill resources give phase-specific Tableau guidance before each set of tool calls.
Human or agent prompt
|
v
MCP server instructions
|
v
Skill resources
data_quality -> governance -> synthetic_data -> design_advisor -> metric_blueprint
-> calculation_builder -> chart_builder -> dashboard_designer -> formatting
-> validation -> quality_review -> documentation
|
v
Workbook tools
create/open -> list_fields -> add/configure -> layout -> save -> validate/upload
|
v
TWB/TWBX artifact + validation evidencePrompts explain what to build. Skills explain how to build it well. Tools make the workbook changes inspectable and repeatable.
The packaged skill architecture is documented in
src/cwtwb/skills/README.md, including its
workflow diagram and the boundary between guidance, explicit mutations, and
validation evidence.
cwtwb keeps its public surface intentionally small:
Level | Meaning |
Core | Stable primitives for normal SDK docs, examples, and MCP workflows |
Advanced | Supported compositions and interaction patterns with more moving parts |
Recipe | Showcase patterns exposed through |
Use list_capabilities or describe_capability when an agent needs to check
whether a requested chart or workbook feature belongs in the stable surface.
The MCP server uses a stateful session model: open or create a workbook, mutate it through explicit tools, then call save_workbook.
Skills are phase-specific operating guides, not generic prompt stuffing.
save_workbook, validate_workbook, validate_workbook_api, and upload_workbook have separate responsibilities so agents do not confuse writing, local checks, semantic validation, and publishing.
The capability registry keeps the product boundary explicit instead of letting showcase examples become accidental API promises.
cwtwb provides four levels of workbook validation:
Level | Description | Requires |
1. Local XSD | Validate against the official Tableau TWB XSD schema (version-aware: 2026.1 or 2026.2) | None (built-in) |
2. REST API Syntactic | Validate XML syntax via Tableau Cloud REST API | Tableau credentials + Tableau Cloud 2026.2+ |
3. REST API Semantic | Full semantic validation without publishing — default cloud check for | Tableau credentials + Tableau Cloud 2026.2+ |
4. Upload + Screenshot | Publish to Tableau Cloud/Server and capture a view image | Tableau credentials + |
# Level 1 — Local XSD (in-memory, no save required)
result = editor.validate_schema()
print(result.to_text())
# Level 3 — REST API semantic validation
from cwtwb.validate.uploader import TableauUploader
uploader = TableauUploader(env_path="project/.env")
result = uploader.validate("output.twb", validation_level="semantic")
# Save with local XSD validation; REST API semantic validation also runs when .env is configured
editor.save("output.twb")# MCP tools
validate_workbook(file_path="output.twb") # Local XSD validation
validate_workbook_api(twb_path="output.twb", validation_level="semantic") # Default cloud semantic validation, no publish
validate_workbook_api(twb_path="output.twb", env_path="project/.env") # Runtime credentials
upload_workbook(twb_path="output.twb") # Publish/openability evidence or TWBX validation
screenshot_workbook(workbook_id="...", view_name="Sheet 1") # Visual check after upload_workbook.twb and .twbx?.twb is the workbook XML. .twbx is the packaged version that bundles the workbook together with extracts and images.
validate_workbook save files?No. validate_workbook() performs local XSD validation on the active in-memory workbook or an existing .twb / .twbx file. It does not write output. save_workbook() is the tool that writes files.
save() perform?save() runs local XSD validation automatically before replacing the final output file. For .twb output, REST API semantic validation also runs when Tableau credentials are configured and the server supports it. Use validate_workbook_api(..., validation_level="semantic") when you want to request the Tableau Cloud/Server validation step directly.
upload_workbook for?upload_workbook publishes a .twb or .twbx to Tableau Cloud/Server. Use it when you explicitly need publish/openability evidence, a workbook ID for screenshots, or .twbx package validation. For the default .twb cloud semantic check, prefer validate_workbook_api because it does not publish or store the workbook. Requires pip install "cwtwb[validate]" and Tableau credentials from environment variables, an explicit env_path, TABLEAU_ENV_FILE, or a .env file next to the workbook.
Install: pip install "cwtwb[validate]"
Copy .env.example to .env
Fill in your Tableau Cloud/Server PAT credentials
Call save_workbook to write the .twb or .twbx
Call validate_workbook_api for the default REST API semantic validation, or upload_workbook only when you also want publish/openability evidence, screenshots, or .twbx validation
Credential lookup order is explicit env_path first, then environment variables, TABLEAU_ENV_FILE, the workbook sibling .env, the current working directory .env, the cwtwb project .env, and finally the user's home .env. Prefer env_path for one-off MCP calls instead of editing MCP server configuration and restarting the server.
If validation reports that tableauserverclient is missing, call get_mcp_status first. It reports the MCP process's Python executable, cwtwb version, and whether the Tableau client is importable without exposing credentials. An env_path change is runtime-scoped and does not require an MCP restart; installing dependencies into a different Python environment does not fix the running server, so install the validation extra into the interpreter reported by get_mcp_status and reconnect only when the runtime or tool schema changes.
uvx cwtwb versus python -m cwtwb.mcp_server?Use uvx cwtwb for the normal MCP workflow. Use python -m cwtwb.mcp_server for local testing without uvx.
For backward compatibility, uvx --from cwtwb cwtwb-mcp, python -m cwtwb.server, and python -m cwtwb.mcp continue to work.
See the online guide.
Add a calculated field to the datasource.
For formula syntax and best practices, read: read_resource('cwtwb://skills/calculation_builder')
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| formula | Yes | ||
| datatype | No | real | |
| field_name | Yes | ||
| field_type | No | ||
| table_calc | No | ||
| internal_name | No | ||
| default_format | No | ||
| validate_formula | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Union existing native sets at the same dimension grain.
| Name | Required | Description | Default |
|---|---|---|---|
| set_name | Yes | ||
| set_names | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Create a dashboard combining multiple worksheets.
Recommended workflow for complex dashboards:
Call list_worksheets to lock worksheet names
Design layout with the user (KPI row, main chart, detail views, filters)
Call generate_layout_json to save the layout as a JSON or YAML file
Call add_dashboard with layout=
Layout options:
str (file path): Path to JSON or YAML layout file (recommended for complex layouts)
dict: Custom declarative layout tree passed inline Native set control (mode dropdown or checkdropdown): {"type": "set_control", "field": "Set name", "worksheet": "View", "mode": "dropdown"}
"auto" (default): Simple vertical fallback — use layout dict or layout file for mixed layouts
"vertical": All worksheets stacked vertically
"horizontal": All worksheets side-by-side
"grid-2x2": 2x2 grid layout
For dashboard design best practices, read: read_resource('cwtwb://skills/dashboard_designer')
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | ||
| height | No | ||
| layout | No | auto | |
| dashboard_name | Yes | ||
| worksheet_names | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Add a filter, highlight, URL, navigation, or parameter dashboard action.
For action_type="parameter", provide source_field,
target_parameter, and a Tableau-serialized clear_value such as
d:2026-02-12, i:0, or s:LROOT:All.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| fields | No | ||
| caption | No | ||
| event_type | No | on-select | |
| action_type | Yes | ||
| aggregation | No | attr | |
| clear_value | No | ||
| source_field | No | ||
| source_sheet | No | ||
| target_sheet | No | ||
| source_sheets | No | ||
| target_sheets | No | ||
| clear_behavior | No | keep-current | |
| dashboard_name | Yes | ||
| field_mappings | No | ||
| target_dashboard | No | ||
| target_parameter | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Add a native dashboard extension with structured manifest and settings.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | ||
| y | No | ||
| width | No | ||
| height | No | ||
| manifest | Yes | ||
| settings | No | ||
| dashboard_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Add a Set Action (edit-group-action) to a dashboard.
The set fills with the marks under the pointer and clears when it leaves, enabling hover-driven labels and calculations.
| Name | Required | Description | Default |
|---|---|---|---|
| caption | No | ||
| event_type | No | on-hover | |
| target_set | Yes | ||
| clear_option | No | exclude-all | |
| source_sheet | Yes | ||
| single_select | No | ||
| dashboard_name | Yes | ||
| selection_mode | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Show/hide a dedicated dashboard sheet container with a native button.
| Name | Required | Description | Default |
|---|---|---|---|
| position | No | ||
| caption_shown | No | Hide | |
| caption_hidden | No | Show | |
| dashboard_name | Yes | ||
| initially_hidden | No | ||
| target_parameters | No | ||
| target_worksheets | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Create a categorical dimension by grouping source-field members.
| Name | Required | Description | Default |
|---|---|---|---|
| groups | Yes | ||
| field_name | Yes | ||
| source_field | Yes | ||
| default_value | No | Other | |
| internal_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Create an ordered Tableau drill hierarchy from bare dimension fields.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| fields | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Add and activate another independent extracted data source.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| filepath | Yes | ||
| table_name | No | Extract |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Add a parameter to the workbook.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| alias | No | ||
| datatype | No | real | |
| max_value | No | ||
| min_value | No | ||
| domain_type | No | range | |
| granularity | No | ||
| default_value | No | 0 | |
| internal_name | No | ||
| allowed_values | No | ||
| default_format | No | ||
| allowed_aliases | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Add a native percentage distribution band on an existing axis.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | per-pane | |
| formula | No | average | |
| symmetric | No | ||
| axis_field | Yes | ||
| fill_color | No | #00000000 | |
| pane_index | No | ||
| percentage | No | ||
| probability | No | 95 | |
| value_field | No | ||
| worksheet_name | Yes | ||
| reverse_palette | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Add a constant or field-backed native filled band on an existing axis.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | per-pane | |
| axis_field | Yes | ||
| fill_color | No | #f5f5f5 | |
| pane_index | No | ||
| lower_field | No | ||
| lower_label | No | ||
| lower_value | No | ||
| upper_field | No | ||
| upper_label | No | ||
| upper_value | No | ||
| lower_formula | No | min | |
| upper_formula | No | max | |
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Add a field-backed reference line to a configured worksheet pane.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| scope | No | per-pane | |
| formula | No | average | |
| tooltip | No | Average = <Value> | |
| axis_field | Yes | ||
| label_type | No | value | |
| pane_index | No | ||
| probability | No | 95 | |
| value_field | Yes | ||
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Create a Tableau set (datasource filter-group) for membership logic.
Use basis_field + top_n to build a top-N set (e.g. Top Central ranked by SUM(Central - Qty)); omit both to create an empty set used as a Set Action target (e.g. Highlighted Manufacturer).
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| members | No | ||
| use_all | No | ||
| set_name | Yes | ||
| direction | No | DESC | |
| aggregation | No | Sum | |
| basis_field | No | ||
| internal_name | No | ||
| dimension_field | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Add a new blank worksheet to the workbook.
| Name | Required | Description | Default |
|---|---|---|---|
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states that a blank worksheet is added, but does not mention side effects (e.g., whether the worksheet becomes active, how it interacts with existing worksheets, or if it requires save). No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (likely returns the worksheet ID or success), the description is minimal. It does not describe the return value or any constraints. For a simple add operation, this is adequate but not complete; the agent may need more context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter ('worksheet_name') with 0% description coverage. The description does not explain what 'worksheet_name' means or any constraints (e.g., uniqueness, length). Since there is only one parameter, the baseline is 4, but the description adds no value beyond the schema, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('a new blank worksheet to the workbook'). It distinguishes from sibling tools like 'clone_worksheet' or 'configure_chart', though it could be more specific about the context (e.g., that it adds to an existing workbook).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'clone_worksheet' or 'add_dashboard'. It does not specify prerequisites (e.g., workbook must be open) or exclusions. The context signals show no annotations, so the description carries the full burden.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze an existing TWB/TWBX file against cwtwb's declared capabilities.
This tool requires a file_path that already exists on disk. It cannot analyze the active in-memory workbook directly and it does not save the current workbook. For a newly generated workbook, call save_workbook first, then pass that saved path to analyze_twb.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Apply a workbook migration and write a migrated TWB plus reports.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | workbook | |
| file_path | Yes | ||
| output_path | Yes | ||
| target_source | Yes | ||
| mapping_overrides | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the tool is likely destructive (applying migrations, writing files) and does not mention idempotency or side effects. The description adds some behavioral context ('write a migrated TWB plus reports') but lacks details on error handling or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the core action. It is front-loaded and contains no filler, but could benefit from slightly more structure (e.g., listing key parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (3 required) and no annotation support, the description is incomplete. It does not explain return values despite having an output schema, nor does it cover migration scope or overrides. Sibling tools with similar purposes demand clearer differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'file_path', 'target_source', 'output_path', and 'scope' implicitly via 'workbook migration', but provides no details on 'mapping_overrides'. The description does not explain parameter meaning or expected formats beyond what the schema minimally indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Apply a workbook migration and write a migrated TWB plus reports', which is a clear verb+resource combination. However, it does not differentiate from the sibling 'migrate_twb_guided' or 'preview_twb_migration', leaving ambiguity about when to use this tool versus those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'migrate_twb_guided' or 'preview_twb_migration'. No context about prerequisites, typical workflow, or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite one worksheet to use replacement fields without touching others.
| Name | Required | Description | Default |
|---|---|---|---|
| replacements | Yes | ||
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states 'rewrite ... using replacement fields' but doesn't mention mutability, whether operation is reversible, or if it requires prior preview. For a mutation tool with no annotations, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. It front-loads the action and scope. Could add a second sentence for when to use or behavior, but current is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (refactoring a worksheet), and no annotations or output schema description, the description is incomplete. It omits what 'replacements' are, whether it validates, and how errors are handled. Output schema exists but description doesn't leverage it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions), but description mentions 'replacement fields', hinting at the 'replacements' parameter. However, it doesn't clarify the format or meaning of the replacement fields, leaving ambiguity. With 0 parameters described in schema, baseline is 3 but could be higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action ('rewrite one worksheet'), resource ('worksheet'), and scope ('without touching others'). It distinguishes from siblings like 'preview_worksheet_refactor' or 'configure_worksheet_style', though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when needing to refactor a single worksheet without affecting others, but lacks explicit when-to-use vs alternatives, such as when to use 'apply_twb_migration' or 'preview_worksheet_refactor' first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report calculated-field datatype/role contradictions without mutation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Clone an existing worksheet and its worksheet window.
| Name | Required | Description | Default |
|---|---|---|---|
| source_worksheet | Yes | ||
| target_worksheet | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose any behavioral traits such as side effects (e.g., whether cloning copies dependencies like calculated fields), authorization requirements, or impact on source worksheet. The description only states what the tool does, not how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and directly states the purpose. It could be considered under-specified, but it is concise and front-loaded with the key action. However, it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (cloning involves copying multiple elements), the description is incomplete. It does not mention what exactly is cloned (e.g., fields, formatting, filters). Although an output schema exists, the description lacks behavioral context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions. The tool description does not add any meaning to the parameters 'source_worksheet' and 'target_worksheet'. It is unclear what format or identifiers are expected (e.g., worksheet names or IDs).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Clone an existing worksheet and its worksheet window', which clearly indicates the action (clone) and the resource (worksheet and its window). It distinguishes from siblings like 'add_worksheet' and 'configure_worksheet_style', though it doesn't explicitly differentiate from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it doesn't mention when to use 'clone_worksheet' instead of 'add_worksheet' or 'configure_worksheet_style'. There is no context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure chart type and field mappings for a worksheet.
For chart type selection and encoding best practices, read: read_resource('cwtwb://skills/chart_builder')
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | ||
| size | No | ||
| color | No | ||
| label | No | ||
| detail | No | ||
| columns | No | ||
| filters | No | ||
| tooltip | No | ||
| color_map | No | ||
| mark_type | No | Automatic | |
| label_runs | No | ||
| map_fields | No | ||
| map_layers | No | ||
| sort_field | No | ||
| wedge_size | No | ||
| label_param | No | ||
| text_format | No | ||
| map_partition | No | ||
| map_layer_mode | No | overlay | |
| measure_values | No | ||
| worksheet_name | Yes | ||
| mark_sizing_off | No | ||
| sort_descending | No | ||
| axis_fixed_range | No | ||
| customized_label | No | ||
| geographic_field | No | ||
| separate_measure_domains | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Configure a showcase recipe chart through the shared recipe registry.
For recipe chart patterns, read: read_resource('cwtwb://skills/chart_builder')
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_args | No | ||
| recipe_name | Yes | ||
| worksheet_name | Yes | ||
| auto_ensure_prerequisites | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Set rich literal/field mark labels while preserving pane calculation context.
| Name | Required | Description | Default |
|---|---|---|---|
| runs | Yes | ||
| pane_index | No | ||
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Set formatted text/field runs or embedded sheets with explicit filter_fields.
| Name | Required | Description | Default |
|---|---|---|---|
| runs | Yes | ||
| pane_index | No | ||
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Link independently aggregated sources in a worksheet without a join.
| Name | Required | Description | Default |
|---|---|---|---|
| link_fields | Yes | ||
| worksheet_name | Yes | ||
| secondary_fields | Yes | ||
| secondary_datasource | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Configure a dual-axis chart composition.
For dual-axis chart patterns and best practices, read: read_resource('cwtwb://skills/chart_builder')
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | ||
| size_1 | No | ||
| size_2 | No | ||
| color_1 | No | ||
| color_2 | No | ||
| columns | No | ||
| filters | No | ||
| label_1 | No | ||
| label_2 | No | ||
| detail_1 | No | ||
| detail_2 | No | ||
| hide_axes | No | ||
| sort_field | No | ||
| color_map_1 | No | ||
| mark_type_1 | No | Bar | |
| mark_type_2 | No | Line | |
| show_labels | No | ||
| mark_color_1 | No | ||
| mark_color_2 | No | ||
| size_value_1 | No | ||
| size_value_2 | No | ||
| synchronized | No | ||
| wedge_size_1 | No | ||
| wedge_size_2 | No | ||
| hide_zeroline | No | ||
| reverse_axis_1 | No | ||
| worksheet_name | Yes | ||
| dual_axis_shelf | No | rows | |
| mark_sizing_off | No | ||
| sort_descending | No | ||
| table_calc_overrides | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Build layered panes with encodings, ordered values and native styles.
sort_mode='computed' orders dimension members before table calculations; 'shelf' explicitly selects shelf sorting, and 'auto' retains default routing. table_calc_context gives explicit overrides a local native instance identity, including map calculations whose dimensions live on mark detail shelves.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | ||
| panes | No | ||
| columns | No | ||
| filters | No | ||
| fold_axes | No | ||
| hide_axes | No | ||
| sort_mode | No | auto | |
| axis_shelf | No | rows | |
| sort_field | No | ||
| synchronized | No | ||
| worksheet_name | Yes | ||
| sort_descending | No | ||
| table_calc_context | No | ||
| table_calc_overrides | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Configure visual subtotals and per-dimension subtotal labels.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Avg. | |
| aggregation | No | Average | |
| measure_fields | Yes | ||
| worksheet_name | Yes | ||
| subtotal_fields | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Complete missing dates for discrete exact-date fields; [] disables completion.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | ||
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Apply worksheet-level styling: background color, axis/grid/border visibility.
pane_mark_style accepts mark-labels-range-field as a public field expression and resolves its native qualified reference for min/max labels.
For formatting best practices, read: read_resource('cwtwb://skills/formatting')
| Name | Required | Description | Default |
|---|---|---|---|
| hide_axes | No | ||
| map_style | No | ||
| axis_style | No | ||
| size_style | No | ||
| color_style | No | ||
| cell_formats | No | ||
| hide_borders | No | ||
| legend_style | No | ||
| pane_formats | No | ||
| hide_reflines | No | ||
| hide_zeroline | No | ||
| label_formats | No | ||
| table_formats | No | ||
| gridline_style | No | ||
| header_formats | No | ||
| hide_droplines | No | ||
| hide_gridlines | No | ||
| worksheet_name | Yes | ||
| disable_tooltip | No | ||
| hide_band_color | No | ||
| pane_cell_style | No | ||
| pane_mark_style | No | ||
| background_color | No | ||
| hide_sort_controls | No | ||
| hide_table_dividers | No | ||
| pane_datalabel_style | No | ||
| hide_col_field_labels | No | ||
| hide_row_field_labels | No | ||
| pane_trendline_hidden | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Extend a continuous date domain and allow calculations on added periods.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| periods | Yes | ||
| period_type | No | year | |
| worksheet_name | Yes | ||
| calculations_on_densified_marks | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Convert TWB, TWBX, YAML or JSON by output suffix without an editor session.
YAML/JSON contain an editable native XML tree, not a simplified chart DSL. Assets are copied alongside definitions; keep these files together. Unknown XML is retained. Only XML syntax is checked, not Tableau runtime behavior. The current editor session is not modified. Existing output requires force.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| input_path | Yes | ||
| output_path | Yes |
Preserve default geometry in a custom Phone/Tablet layout with shared IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| device_name | No | Phone | |
| dashboard_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Create a new workbook from a TWB or TWBX template file.
| Name | Required | Description | Default |
|---|---|---|---|
| template_path | No | ||
| workbook_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not state whether the tool modifies existing files, requires specific permissions, or if the creation is reversible. The word 'create' implies a write operation, but no further details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly states the tool's purpose. It is concise and front-loaded, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the relatively simple operation (creation from template), the description provides the core purpose. However, it lacks details on parameter behavior, error conditions, or what happens to existing workbooks. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, meaning the description adds no detail beyond the schema. However, the parameter names ('template_path', 'workbook_name') are fairly self-explanatory. The description clarifies that the template is from a TWB/TWBX file, which adds context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action ('create a new workbook') and the source material ('from a TWB or TWBX template file'). However, it does not differentiate from siblings like 'generate_workbook_from_run' or 'save_workbook', which could create ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives (e.g., 'generate_workbook_from_run' or 'open_workbook'). It does not mention prerequisites, such as whether the template file must exist or be provided via a path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe one declared capability and its support tier.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It accurately states the tool's behavior (describing one capability) but does not disclose side effects, permissions, or error conditions. The description is honest 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity is low (simple retrieval with 2 parameters and an output schema), the description is mostly adequate. However, the lack of parameter semantics and usage guidance reduces completeness for an agent without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 what 'kind' and 'name' refer to or how to obtain valid values. The description adds no meaning beyond the schema field titles, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a capability and its support tier, using a specific verb ('describe') and resource ('capability'). It distinguishes from sibling tools like 'list_capabilities' by focusing on a single capability, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., 'list_capabilities'). The description lacks context on prerequisites or appropriate usage scenarios, leaving the agent to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize the non-core capability gap of a TWB template.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention if the tool is read-only, has side effects, requires authentication, or any constraints. The description only states the purpose but not the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no unnecessary words. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one parameter, no annotations, but an output schema exists), the description is too sparse. It does not explain the tool's purpose relative to siblings, the format of the summary, or prerequisites. The output schema may provide return structure, but the description should still set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the input schema provides no description for the 'file_path' parameter. The description does not explain what 'file_path' should point to (e.g., a TWB file, a specific format). With only one parameter, the description should add context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Summarize the non-core capability gap of a TWB template', which is a specific verb ('Summarize') and resource ('non-core capability gap of a TWB template'). It is clear and distinct from sibling tools like 'profile_twb_for_migration' or 'analyze_twb'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'profile_twb_for_migration' or 'analyze_twb'. The description does not explain what constitutes a 'non-core capability gap' or in what context this is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Derive a scrolling Phone layout from the default dashboard objects.
| Name | Required | Description | Default |
|---|---|---|---|
| dashboard_name | Yes | ||
| worksheet_height | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Add an INDEX() detail table calculation to trigger Tableau densification.
| Name | Required | Description | Default |
|---|---|---|---|
| field_name | No | Domain Completion Index | |
| ordering_type | No | Rows | |
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Bind exact worksheet names to a Gallery template and validate the layout DSL.
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | No | ||
| template_name | Yes | ||
| worksheet_slots | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Generate and save a dashboard layout file.
Recommended workflow:
Call list_worksheets to get available worksheet names
Design the layout with the user (show ASCII preview for confirmation)
Call this tool to save the layout as a JSON or YAML file
Call add_dashboard with layout=
The layout_tree uses the declarative container DSL:
{"type": "container", "direction": "vertical"|"horizontal", "children": [...]}
{"type": "worksheet", "name": ""}
Use "fixed_size" (int, pixels) for KPI rows and filter sidebars
Use "weight" (int, relative) for main analytical areas
| Name | Required | Description | Default |
|---|---|---|---|
| layout_tree | Yes | ||
| output_path | Yes | ||
| ascii_preview | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Generate and save a dashboard layout YAML file.
Recommended workflow:
Call list_worksheets to get available worksheet names
Design the layout with the user (show ASCII preview for confirmation)
Call this tool to save the layout as a YAML file
Call add_dashboard with layout=
The layout_tree uses the same declarative container DSL as generate_layout_json.
| Name | Required | Description | Default |
|---|---|---|---|
| layout_tree | Yes | ||
| output_path | Yes | ||
| ascii_preview | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Report cwtwb MCP server version, workbook state, and safe usage guardrails.
Use this when an AI client seems stale, cannot see expected tools, or is about to edit MCP configuration to switch Tableau credentials. This tool never returns secret values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Define a primary aggregate proxy for a secondary source field.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| field | Yes | ||
| secondary_datasource | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Initialize an existing native filter action's targets with overridable members.
| Name | Required | Description | Default |
|---|---|---|---|
| members | Yes | ||
| action_name | Yes | ||
| dashboard_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Preview how an Excel workbook will be interpreted before connection setup.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| sheet_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Inspect the first-sheet schema of a target Excel datasource.
| Name | Required | Description | Default |
|---|---|---|---|
| target_source | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses it inspects only the first sheet of Excel, but does not mention any side effects or permissions. With no annotations, this is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 10 words, no filler. Front-loaded with verb and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 1 parameter, no annotations, but with an output schema (which presumably explains return value), the description is nearly complete. Could add that it returns field names and types, but output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description adds no meaning to the 'target_source' parameter. The description only mentions 'target Excel datasource' but does not explain what 'target_source' is or how to specify it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb 'inspect' and resource 'first-sheet schema of a target Excel datasource'. It clearly distinguishes from siblings like 'intake_datasource_schema' by specifying Excel and first-sheet scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. However, from context it's implied to inspect schema before using other datasource tools. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link matching categorical filters so one control filters all given sheets.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| worksheet_names | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
List cwtwb's declared capability boundary.
This reports what workbook features/charts are supported by cwtwb. It does not enumerate callable MCP tools and should not be used to infer whether a tool like add_dashboard or save_workbook exists.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
List dashboards and their worksheet zones in the current workbook.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the tool as listing dashboards and zones, implying a read-only operation, which is reasonable but lacks details on side effects or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous information. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with zero parameters and an output schema exists (not shown). The description is sufficient given the simplicity, though it could mention that it operates on the currently open workbook.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with zero parameters, so the description does not need to add parameter info. It correctly states the scope (current workbook) which adds context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists dashboards and their worksheet zones in the current workbook, with a specific verb and resource. However, it does not differentiate from siblings like 'add_dashboard' or 'list_worksheets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'add_dashboard' or 'list_worksheets'). The context of 'current workbook' is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available fields in the current workbook datasource.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It states the tool 'lists' fields, implying a read-only operation with no side effects. However, it does not clarify behavior like caching, pagination, or what 'available' means exactly (e.g., include hidden fields?). The description is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the key action. Every word earns its place. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, presence of output schema, and low complexity, the description is nearly complete. It identifies the resource and scope. It could optionally mention that the output includes field names and types, but the output schema presumably covers that. Slight lack of detail on what 'available' means, but adequate for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add parameter details. The description correctly implies no configuration is needed. With 100% schema coverage (trivially), a baseline of 3 applies, but the description adds value by specifying the source ('current workbook datasource').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available fields in the current workbook datasource. It specifies the resource ('fields') and scope ('current workbook datasource'). While it distinguishes from sibling tools like 'add_calculated_field' and 'remove_calculated_field', it does not explicitly differentiate from potential field-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before other actions that require knowledge of available fields (e.g., adding calculated fields). However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List packaged Gallery layouts and their explicit worksheet slots.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
List worksheet names in the current workbook.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it lists 'names', which is a non-destructive read operation. Since no annotations are provided, the description carries the full burden. It clearly indicates no side effects, though it doesn't mention what happens if the workbook is empty or if there are many worksheets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 5 words, perfectly concise and front-loaded. Every word is necessary and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema needed since output is presumably list of strings), the description is complete. It tells the agent exactly what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is nothing to explain. The description adds no parameter semantics, but this is acceptable since there are none. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists worksheet names in the current workbook, using a specific verb ('list') and resource ('worksheet names'). It is distinct from siblings like list_dashboards, list_fields, and add_worksheet, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to know worksheet names, and it is clearly a read-only operation. However, it does not explicitly state when not to use it or compare to alternatives like list_fields or list_dashboards, which might be relevant if the agent needs other information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open an existing workbook (.twb or .twbx) for in-place worksheet editing.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states 'in-place worksheet editing', which implies the tool modifies the workbook directly. However, it does not disclose whether it requires specific permissions, locks the file, or how it handles unsaved changes. The behavioral transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the purpose. Every word is necessary, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (not shown but present) and a single parameter, the description is minimally adequate. However, it lacks context about what happens after opening (e.g., if the workbook is loaded into memory, if subsequent tools operate on it) and does not mention prerequisites like file existence or format validity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but there is only one parameter (file_path). The description adds no additional meaning beyond the parameter name; it does not specify path format, allowed file extensions (though implied), or whether absolute/relative paths are accepted. With low coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Open' and the resource 'existing workbook', specifying file types (.twb or .twbx) and the purpose 'for in-place worksheet editing'. It distinguishes this from sibling tools like 'create_workbook' or 'save_workbook' by focusing on opening an existing file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to edit worksheets in an existing workbook, but it does not explicitly state when not to use it or provide alternatives. Among many sibling tools, it doesn't clarify that for creating new workbooks one should use 'create_workbook' or for saving use 'save_workbook'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview a workbook migration onto a target datasource.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | workbook | |
| file_path | Yes | ||
| target_source | Yes | ||
| mapping_overrides | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose whether the tool is read-only or destructive, what side effects occur (if any), or if it modifies any state. The term 'preview' suggests no mutation, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it is too terse and lacks necessary detail, making it underspecified rather than efficiently packed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0% schema coverage, no annotations, but has an output schema), the description is incomplete. It does not explain what the preview returns (despite output schema existing), nor does it provide context about when to use this tool in the migration workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain any parameter. The description mentions 'migration' and 'target datasource' vaguely, but does not elaborate on 'file_path', 'target_source', 'scope', or 'mapping_overrides'. The purpose of 'scope' with default 'workbook' and 'mapping_overrides' is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Previews a workbook migration onto a target datasource.' The verb 'preview' and resource 'workbook migration' are clear, but the description is vague about what 'preview' entails (e.g., does it show potential issues, a diff, or a success/failure indicator?). It does not distinguish this from siblings like 'apply_twb_migration' or 'profile_twb_for_migration'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs. alternatives like 'apply_twb_migration' or 'migrate_twb_guided'. There is no mention of prerequisites (e.g., need to profile first) or conditions under which preview is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview worksheet-scoped field rewrites without mutating the workbook.
| Name | Required | Description | Default |
|---|---|---|---|
| replacements | Yes | ||
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must convey behavior. It clearly states 'without mutating the workbook' (read-only preview). However, it does not disclose return value structure, whether changes are simulated, or any side effects. The output schema exists but is not described; without it, the agent may not know what the preview returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely captures purpose and key constraint. No wasted words; front-loaded with action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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. However, the tool has nested objects and 0% schema coverage, so the description should explain the replacements map. It partially compensates with 'worksheet-scoped field rewrites' but lacks detail on what constitutes a rewrite. Completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not describe the parameters 'worksheet_name' or 'replacements' beyond their names. The description mentions 'worksheet-scoped' hinting at worksheet_name, but does not explain that 'replacements' is a map from old field names to new names. The agent has no semantic guidance beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Preview worksheet-scoped field rewrites without mutating the workbook,' which clearly specifies the action (preview), scope (worksheet-scoped field rewrites), and key trait (non-mutating). It distinguishes from sibling tools like 'apply_worksheet_refactor' (which applies changes) and 'preview_twb_migration' (which is workbook-level). However, the term 'field rewrites' could be more explicit about what is being replaced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when wanting to see the effect of field replacements before committing, contrasting with 'apply_worksheet_refactor'. No explicit when-not-to-use or alternative guidance is provided. The sibling list includes 'preview_twb_migration' and 'apply_worksheet_refactor', but the description does not directly compare.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Profile workbook datasources and worksheet scope before migration.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | workbook | |
| file_path | Yes | ||
| target_source | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool profiles datasources and worksheet scope, implying it is a read-only analysis tool. However, it does not disclose side effects, authentication needs, or whether it modifies the workbook. The term 'profile' suggests no destructive action, but this is implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the verb and resource. It is appropriately sized, but could benefit from a brief mention of parameters or output without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema exists, and multiple sibling tools), the description is minimally adequate. It covers the core purpose but lacks detail on parameters and usage context. The presence of an output schema somewhat mitigates the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The description does not explain what 'file_path', 'scope', or 'target_source' mean or how they affect behavior. The parameter names are self-explanatory to some extent, but the description fails to add semantic value beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Profile workbook datasources and worksheet scope before migration' clearly identifies the tool's purpose with a specific verb ('profile') and resource ('workbook datasources and worksheet scope'). It distinguishes from sibling tools like 'analyze_twb' and 'migrate_twb_guided' by focusing on pre-migration profiling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'analyze_twb' or 'preview_twb_migration'. It does not mention prerequisites or conditions that would trigger its use, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan source and target schema and propose a field mapping.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | workbook | |
| file_path | Yes | ||
| target_source | Yes | ||
| mapping_overrides | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Scan source and target schema.' It does not disclose if this is a read-only operation, whether it modifies state, what permissions are needed, or how long it might take. The output schema exists but the description doesn't hint at what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, which is very concise. However, it is too minimal; it sacrifices clarity and completeness for brevity. Still, it avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema, the description does not need to explain return values, but it still lacks context on tool behavior, prerequisites, and how to use parameters. The tool has 4 parameters with 0% schema description coverage, so more detail in the description is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description adds no parameter details. The description does not explain the meaning of 'file_path,' 'target_source,' 'scope,' or 'mapping_overrides.' The schema provides some hints (e.g., 'scope' defaults to 'workbook'), but the description fails to clarify how these parameters affect the mapping proposal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Scan' and the resource 'source and target schema' to 'propose a field mapping.' It distinguishes itself from siblings like 'inspect_target_schema' and 'migrate_twb_guided' by focusing on proposing a mapping rather than just inspecting or executing migration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'inspect_target_schema' or 'migrate_twb_guided.' There is no mention of prerequisites (e.g., schema must be available), nor any exclusion criteria (e.g., when not to use).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend compatible Gallery templates with scores and reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| kpi_count | No | ||
| chart_count | No | ||
| chart_types | No | ||
| filter_count | No | ||
| primary_intent | No | ||
| has_temporal_data | No | ||
| has_geographic_data | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Remove a previously added calculated field.
| Name | Required | Description | Default |
|---|---|---|---|
| field_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the removal action, which implies a destructive operation (deletion). However, it does not clarify whether the field is permanently deleted or can be recovered, nor does it mention any prerequisites (e.g., field must exist). The description is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action. Every word is necessary and there is no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no annotations, and an output schema exists. Given the simplicity, the description is reasonably complete but could mention that the field must exist and that the operation may affect formulas depending on it. The output schema likely covers return values, so that is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'field_name' with 0% schema description coverage. The description adds meaning by specifying it's a 'previously added calculated field', clarifying that the field must exist. This provides context beyond the parameter name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Remove' and the resource 'calculated field', clearly stating the action and object. It distinguishes from sibling tools like 'add_calculated_field' by implying the inverse operation. However, it could be more specific about the scope (e.g., from the active worksheet or workbook).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for removing a calculated field that was previously added. It does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives. The sibling 'add_calculated_field' is the obvious counterpart, but no explicit comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview or explicitly apply selected calculated-field metadata repairs.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| field_names | No | ||
| issue_codes | No | ||
| datasource_names | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Save the active workbook as a .twb or .twbx file. Use a .twbx extension to produce a packaged workbook (ZIP) that bundles the XML with any data extracts and images carried over from the source .twbx.
This is the only default MCP tool that writes the active in-memory workbook to disk. After create_workbook/open_workbook plus worksheet/chart/dashboard edits, call save_workbook with the desired output_path to create the final .twb or .twbx file. validate_workbook and analyze_twb do not save files.
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Screenshot a published workbook's view for human review.
Use after upload_workbook to capture a visual snapshot. The screenshot is saved locally for human inspection.
Args: workbook_id: The workbook ID returned by upload_workbook. output_dir: Directory to save screenshot (default: output/validation). view_index: Index of the view to screenshot (default: 0). view_name: Name of the view to screenshot (overrides view_index). env_path: Optional path to a .env file with Tableau credentials. Explicit env_path takes priority over process environment variables.
Returns: {success, path, view_name, view_id, size_kb, error}
| Name | Required | Description | Default |
|---|---|---|---|
| env_path | No | ||
| view_name | No | ||
| output_dir | No | output/validation | |
| view_index | No | ||
| workbook_id | Yes |
Select the source for subsequent field and worksheet authoring.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Map ordered categorical tuples to colors, including Measure Names.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | ||
| mappings | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Configure the workbook datasource to use a local CSV connection.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| charset | No | utf-8-sig | |
| filepath | Yes | ||
| delimiter | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Set datasource weekday origin for date-part headers and week calculations.
| Name | Required | Description | Default |
|---|---|---|---|
| start_of_week | No | sunday |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Configure the workbook datasource to use a local Excel connection.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| filepath | Yes | ||
| sheet_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not explain whether the connection replaces an existing one, what happens to existing data, or any side effects. It also doesn't mention permission requirements or file accessibility. The output schema exists but isn't referenced in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words, efficient and front-loaded. It uses active voice and clear terminology. However, it could be slightly improved by adding a brief note about parameters or behavior without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, 0% schema coverage, no annotations, and a task that likely involves file I/O and connection configuration, the description is incomplete. It lacks information about return values (output schema exists but not described), error conditions, and parameter details. The output schema existence suggests richer behavior, but the description doesn't leverage it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'local Excel connection' but doesn't describe individual parameters like filepath, sheet_name, or fields. The schema provides names, but the description adds no additional meaning, missing an opportunity to clarify the purpose of sheet_name (e.g., which sheet to use) or fields (e.g., column mapping).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures a workbook datasource to use a local Excel connection, specifying the action (configure), resource (workbook datasource), and target type (local Excel connection). It distinguishes itself from sibling tools like set_hyper_connection or set_mysql_connection, which target different datasource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., set_hyper_connection for Hyper files). It doesn't mention prerequisites like whether a workbook must already be open or if the Excel file must exist. Sibling tools suggest different datasource types, but the description provides no comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the native fiscal year starting month on a date field and dependencies.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| month | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Set or clear a field's default Tableau display format.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| default_format | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Assign or clear a field's geographic role.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| geographic_role | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Set geographic lookup context for generated map coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| country | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Configure the workbook datasource to use a local Hyper extract connection.
| Name | Required | Description | Default |
|---|---|---|---|
| tables | No | ||
| filepath | Yes | ||
| table_name | No | Extract | |
| relationships | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Alias actual Measure Names members, including table calculation measures.
| Name | Required | Description | Default |
|---|---|---|---|
| mapping | Yes | ||
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Configure the workbook datasource to use a local MySQL connection.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | 3306 | |
| dbname | Yes | ||
| server | Yes | ||
| username | Yes | ||
| table_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must fully disclose behavior. It does not state whether the tool modifies the workbook immediately, requires an open workbook, or what happens on failure. No mention of side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. But lacks structure; could benefit from a note about required vs optional parameters or order of operations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (4 required), no output schema info (though output schema exists, its content is not described), and no annotations, the description is too sparse to ensure correct invocation. Missing details like whether the connection is persistent or temporary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no descriptions for parameters. The description adds no parameter-level semantics; it just names the tool. Parameters like 'server', 'dbname' are self-explanatory but 'table_name' could be confused with a table to create or select. No hint about how 'port' default is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it configures a workbook datasource for a local MySQL connection, which is clear. However, 'local' may be confusing as parameters include a 'server' field. It distinguishes from sibling connection tools (set_excel_connection, etc.) but not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs other connection tools (set_excel_connection, set_hyper_connection, etc.). No prerequisites or alternative suggestions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Embed local shape assets and map categorical members to the native palette.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| shapes | Yes | ||
| palette | No | Custom |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Configure the workbook datasource to use a Tableau Server connection.
This edits the workbook datasource connection only. It does not configure Tableau REST API/PAT credentials for validate_workbook_api, upload_workbook, or screenshot_workbook; pass env_path to those validation tools instead.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | 82 | |
| dbname | Yes | ||
| server | Yes | ||
| username | Yes | ||
| directory | No | /dataserver | |
| table_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Set or clear a plain-text worksheet caption.
| Name | Required | Description | Default |
|---|---|---|---|
| caption | Yes | ||
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must carry behavioral information. It states the tool sets or clears a caption, implying a mutation. However, it does not disclose if the operation is reversible, if it requires permissions, or what the output schema indicates (return value).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the core functionality with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters and no nested objects, the description is reasonably complete. However, it lacks details about return value (output schema exists but description doesn't mention it) and edge cases like clearing caption behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains that the caption is 'plain-text' and that the tool can 'clear' (likely by empty string). This adds value beyond the schema, which only lists names and types. However, it does not detail what 'clear' means in terms of input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets or clears a plain-text worksheet caption, using the verb 'set' and specifying the resource (worksheet caption). It distinguishes from siblings like 'set_worksheet_hidden' by focusing on caption content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For instance, there is no mention that to clear a caption one can pass an empty string, nor when to use this over other worksheet modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set or clear the visible plain-text worksheet title.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| worksheet_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Publish a .twb/.twbx to Tableau Cloud for openability or screenshots.
Prefer validate_workbook_api for the default cloud semantic validation path because it does not publish or store the workbook. Use upload_workbook only when you explicitly need a published workbook_id, visual screenshot, TWBX packaging validation, or publish/openability evidence.
Args: twb_path: Path to .twb or .twbx file. data_path: Optional data file (.xlsx/.xls/.hyper) to package. name: Workbook name on Tableau Cloud (defaults to filename stem). overwrite: Whether to overwrite existing workbook with same name. env_path: Optional path to a .env file with Tableau credentials. Explicit env_path takes priority over process environment variables.
Returns: {success, workbook_id, workbook_url, views, twbx_path, twbx_size_kb, error}
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| env_path | No | ||
| twb_path | Yes | ||
| data_path | No | ||
| overwrite | No |
Check Tableau function names without mutating the active workbook.
| Name | Required | Description | Default |
|---|---|---|---|
| formula | Yes | ||
| field_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Validate a workbook against the official Tableau TWB XSD schema.
Checks whether the generated XML conforms to Tableau's published schema. This tool does not save or export the active workbook. If file_path is omitted, it validates the current in-memory workbook before save; if file_path is provided, it validates an existing .twb/.twbx file on disk. Call save_workbook when you need to write the workbook to a file.
Args: file_path: Path to a .twb or .twbx file to validate. If omitted, validates the currently open workbook (in memory, before save).
Returns: PASS/FAIL summary with error details.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Validate a .twb file via Tableau Cloud REST API (no publish).
This performs semantic validation that checks whether the workbook will actually open in Tableau — beyond what local XSD schema validation can detect (calculated field formulas, field references, data source connectivity, etc.). The file is NOT stored on the server.
Only .twb files are supported. For .twbx files, use upload_workbook.
Requires Tableau Cloud June 2026+ / Server 2026.2+ (API version 3.29+).
Args: twb_path: Path to .twb file. validation_level: "syntactic" (XSD only) or "semantic" (full, default). env_path: Optional path to a .env file with Tableau credentials. Explicit env_path takes priority over process environment variables.
Returns: {success, validation_level, valid, errors, warnings, error}
| Name | Required | Description | Default |
|---|---|---|---|
| env_path | No | ||
| twb_path | Yes | ||
| validation_level | No | semantic |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.28.0add_calculated_field3 fields changedInput schema / properties / internal_nameAdded value: +{
+ "default": "",
+ "title": "Internal Name",
+ "type": "string"
+}Input schema / properties / table_calcAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Table Calc"
+}Input schema / properties / validate_formulaAdded value: +{
+ "default": true,
+ "title": "Validate Formula",
+ "type": "boolean"
+}add_combined_setadd_dashboard1 field changedInput schema / properties / layout / defaultPrevious value: -"vertical"New value: +"auto"add_dashboard_action11 fields changedInput schema / properties / aggregationAdded value: +{
+ "default": "attr",
+ "title": "Aggregation",
+ "type": "string"
+}Input schema / properties / clear_behaviorAdded value: +{
+ "default": "keep-current",
+ "title": "Clear Behavior",
+ "type": "string"
+}Input schema / properties / clear_valueAdded value: +{
+ "default": "",
+ "title": "Clear Value",
+ "type": "string"
+}Input schema / properties / field_mappingsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Field Mappings"
+}Input schema / properties / source_fieldAdded value: +{
+ "default": "",
+ "title": "Source Field",
+ "type": "string"
+}Input schema / properties / source_sheet / defaultAdded value: +""Input schema / properties / source_sheetsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Source Sheets"
+}Input schema / properties / target_dashboardAdded value: +{
+ "default": "",
+ "title": "Target Dashboard",
+ "type": "string"
+}Input schema / properties / target_parameterAdded value: +{
+ "default": "",
+ "title": "Target Parameter",
+ "type": "string"
+}Input schema / properties / target_sheetsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Target Sheets"
+}Input schema / requiredPrevious value: -[
- "dashboard_name",
- "action_type",
- "source_sheet"
-]New value: +[
+ "dashboard_name",
+ "action_type"
+]add_dashboard_extensionadd_dashboard_set_actionadd_dashboard_toggle_buttonadd_groupadd_hierarchyadd_hyper_datasourceadd_parameter3 fields changedInput schema / properties / aliasAdded value: +{
+ "default": "",
+ "title": "Alias",
+ "type": "string"
+}Input schema / properties / allowed_aliasesAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Allowed Aliases"
+}Input schema / properties / internal_nameAdded value: +{
+ "default": "",
+ "title": "Internal Name",
+ "type": "string"
+}add_percentage_bandadd_reference_bandadd_reference_lineadd_setaudit_calculated_fieldsbuild_analysis_briefbuild_execution_planbuild_wireframeconfigure_chart4 fields changedInput schema / properties / map_layer_modeAdded value: +{
+ "default": "overlay",
+ "title": "Map Layer Mode",
+ "type": "string"
+}Input schema / properties / map_partitionAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Map Partition"
+}Input schema / properties / separate_measure_domainsAdded value: +{
+ "default": false,
+ "title": "Separate Measure Domains",
+ "type": "boolean"
+}Input schema / properties / sort_fieldAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Sort Field"
+}configure_custom_labelconfigure_custom_tooltipconfigure_datasource_blendconfigure_dual_axis2 fields changedInput schema / properties / sort_fieldAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Sort Field"
+}Input schema / properties / table_calc_overridesAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Table Calc Overrides"
+}configure_layered_chartconfigure_subtotalsconfigure_worksheet_domain_rangeconfigure_worksheet_style8 fields changedInput schema / properties / color_styleAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Color Style"
+}Input schema / properties / gridline_styleAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Gridline Style"
+}Input schema / properties / hide_sort_controlsAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Hide Sort Controls"
+}Input schema / properties / legend_styleAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Legend Style"
+}Input schema / properties / map_styleAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Map Style"
+}Input schema / properties / pane_formatsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Pane Formats"
+}Input schema / properties / size_styleAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Size Style"
+}Input schema / properties / table_formatsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Table Formats"
+}configure_worksheet_time_seriesconfirm_authoring_stageconvert_workbookcopy_default_device_layoutdraft_authoring_contractenable_automatic_phone_layoutenable_domain_completionfinalize_analysis_brieffinalize_authoring_contractfinalize_wireframegenerate_gallery_layoutgenerate_layout_yamlgenerate_workbook_from_runget_client_interaction_capabilitiesget_mcp_statusget_run_statusimport_blended_fieldinitialize_dashboard_filter_actioninspect_excel_connectionintake_datasource_schemainteractive_stage_confirmationlink_worksheet_filterslist_authoring_runslist_gallery_templatesmigrate_twb_guidedrecommend_gallery_templatesreopen_authoring_stagerepair_calculated_field_issuesresume_authoring_runreview_authoring_contractreview_authoring_contract_for_runscreenshot_workbookselect_datasourceset_compound_color_paletteset_csv_connectionset_date_optionsset_field_fiscal_year_startset_field_formatset_field_geographic_roleset_geocoding_contextset_hyper_connection1 field changedInput schema / properties / relationshipsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Relationships"
+}set_measure_name_aliasesset_shape_paletteset_worksheet_titlestart_authoring_runupload_workbookvalidate_formulavalidate_workbook_apiv0.18.1add_calculated_fieldadd_dashboardadd_dashboard_actionadd_parameteradd_worksheetanalyze_twbapply_twb_migrationapply_worksheet_refactorbuild_analysis_briefbuild_execution_planbuild_wireframeclone_worksheetconfigure_chartconfigure_chart_recipeconfigure_dual_axisconfigure_worksheet_styleconfirm_authoring_stagecreate_workbookdescribe_capabilitydiff_template_gapdraft_authoring_contractfinalize_analysis_brieffinalize_authoring_contractfinalize_wireframegenerate_layout_jsongenerate_workbook_from_runget_client_interaction_capabilitiesget_run_statusinspect_target_schemaintake_datasource_schemainteractive_stage_confirmationlist_authoring_runslist_capabilitieslist_dashboardslist_fieldslist_worksheetsmigrate_twb_guidedopen_workbookpreview_twb_migrationpreview_worksheet_refactorprofile_twb_for_migrationpropose_field_mappingremove_calculated_fieldreopen_authoring_stageresume_authoring_runreview_authoring_contractreview_authoring_contract_for_runsave_workbookset_excel_connectionset_hyper_connectionset_mysql_connectionset_tableauserver_connectionset_worksheet_captionset_worksheet_hiddenstart_authoring_runvalidate_workbookScored across 56 tools
Most tools target distinct actions like adding fields, configuring charts, or managing authoring runs. However, tools like 'build_analysis_brief' and 'finalize_analysis_brief' could be confused, and 'review_authoring_contract' vs 'review_authoring_contract_for_run' have overlapping purposes.
Tools predominantly use verb_noun pattern (e.g., add_calculated_field, open_workbook), but there are inconsistencies like 'interactive_stage_confirmation' (adjective_noun) and 'profile_twb_for_migration' (verb_noun_preposition). The naming is readable but not fully consistent.
With 56 tools, the server is overly large for a focused authoring assistant. Many tools are specialized for guided workflows, making the surface feel bloated. A smaller, more focused set would be more coherent.
The tool set covers a broad range of workbook operations: creation, editing, validation, migration, and connection management. Minor gaps exist, such as lacking direct tool for deleting worksheets or dashboards, but the overall lifecycle is well-covered.
AI data analyst: ask about your Excel, CSV, GA4 or database data and get charts and dashboards back
Group, aggregate and pivot spreadsheet or CSV data from your AI chat: filters, sums, sorts.
Open, inspect, filter, edit and convert xlsx and csv files from your AI chat. Processing is local.
Open, inspect, filter, edit and convert xlsx and csv files from your AI chat. Processing is local.
