Tableau Knowledge MCP

Overview Schema Source Related Servers Discussions Admin

Add semantic context from a document

create_semantic_context_from_document

Upload a local document and convert each line into Tableau semantic context, such as a KPI glossary or business-rules note, for a node or the whole graph.

Instructions

WRITE: upload a local document (.txt, .md, .csv, .pdf, .docx, .xlsx; max 2 MB) and let Tableau turn it into semantic context, e.g. a KPI glossary or a business-rules note.

`file_path` is a path on the machine running this server; the file's content is sent to your
Tableau site, so confirm the file with the user first. Set exactly ONE of `target_node_id` (an
exact node id) or `is_global=true`, as for create_semantic_context (some sites accept only
graph-wide context). Tableau makes each line a statement (headings too), so write one rule
per line. Returns the new context with its statements and any `statements_skipped`.

Uses Tableau Knowledge's undocumented web-app API, which can change without notice.

Input Schema

Name	Required	Description	Default
`name`	No
`graph_id`	No
`file_path`	Yes
`is_global`	No
`target_node_id`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Nov 5, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing that file contents leave the machine and are sent to the user's Tableau site, that the tool relies on an undocumented web-app API that may change without notice, and that each line becomes a statement (headings included). Those are exactly the operational and side-effect facts the readOnly/openWorld hints cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the operation type ('WRITE:') and then spends its sentences on format limits, targeting constraints, authoring advice and API risk — all of which earn their place. It is slightly dense, stacking many clauses per sentence, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with an output schema, it covers the risky parts: data egress, API instability, exclusive targeting, and the line-per-statement authoring rule. The only gap is the unexplained name and graph_id parameters, which matters more here because the schema itself documents nothing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description has to carry the load, and it explains file_path (a path on the server's machine), target_node_id (an exact node id) and is_global, including the mutually exclusive targeting rule. The two remaining parameters, name and graph_id, are never mentioned, leaving their role and interaction with is_global/target_node_id unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('upload a local document ... turn it into semantic context'), enumerates the accepted formats and size cap, and implicitly separates itself from create_semantic_context by being the document-based variant. An agent can tell which sibling to pick without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete pre-call conditions: confirm the file with the user first, and set exactly one of target_node_id or is_global, plus the caveat that some sites accept only graph-wide context. It never explicitly states when to prefer this over create_semantic_context, so it stops short of a full when/when-not routing rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.