Biztory Tableau Knowledge Mcp

Report the connected Tableau site and its knowledge graphs: server URL, site, product version, auth method, whether Tableau Knowledge is available, and every graph (id, name, status, is_primary). Good first call: it confirms the connection and gives the graph ids the other tools accept as `graph_id` (omit `graph_id` to use the primary graph).

Takes no parameters.

Find graph nodes by MEANING (semantic search), not exact name: "revenue" can match a field named "Net Sales". Returns ranked matches with a 0-1 `score`; when a semantic statement matched, it is shown under the node's `semantic_statements`. - `node_type` narrows to one type: PDS (published data source), WORKBOOK, SHEET, DASHBOARD, EMBEDDED_DATASOURCE, TABLE, FIELD, WAREHOUSE_TABLE, WAREHOUSE_COLUMN, CONNECTION, SCHEMA, SITE, SEMANTIC_CONTEXT, SEMANTIC_CONTEXT_EXTERNAL. - `scope_id` limits the search to one data source's subtree (a PDS node id plus its tables and fields). - `limit` 1-100 (default 10); `threshold` drops matches scoring below it (0-1). Use the returned `id`s with get_node, list_edges, lineage and impact_analysis.

Get one node with its properties, its semantic statements (the business context attached to it), and the child nodes it points to (`connected_nodes`, each with the edge type). `node` is a node id, or a plain-language description that is resolved by semantic search (the response then includes `resolution` with the match score and alternatives). Set `include_children` false to skip `connected_nodes` on large containers.

List the edges around one node, each with its `direction` (outgoing/incoming) and the node on the other end. One hop only; use lineage for the wider neighborhood. `node` is a node id or a plain-language description. `edge_type` narrows to one of: CONTAINS, HAS, JOINS, DEPENDS_ON, LINEAGE, SEMANTIC_EQUIV, DESCRIBES. `direction` is "outgoing" or "incoming"; omit for both.

The lineage neighborhood of a node: every node reachable within 10 steps, upstream AND downstream, along lineage/dependency edges (LINEAGE, DEPENDS_ON), e.g. a data source and the workbooks built on it. Answers "where does this come from?" and "what uses it?". Containment (a table HAS a field, a workbook CONTAINS a sheet) is not followed, so a single field often returns only itself; use list_edges or get_node to see what contains it. `node` is a node id or a plain-language description. Returns the anchor node, `nodes`, `edges` (source_id -> target_id, with type), and counts by node and edge type. For "what breaks if this changes?", impact_analysis is more direct.

What breaks if this changes: every asset that depends on the node, directly OR transitively (up to 10 steps, following DEPENDS_ON), e.g. the calcs, sheets, dashboards and workbooks downstream of a column. The node itself is not included. `node` is a node id or a plain-language description. Returns `total`, `counts_by_type`, and `affected_assets` sorted by type then name.

List the published data sources and workbooks connected to the knowledge graph, i.e. what the graph has been built from. `node_type` "PDS" or "WORKBOOK" narrows it; omit for both. `ingest` shows the graph's latest ingestion (status running/completed, per-asset results). With `site_search` (part of a name, case-insensitive), it instead searches the whole SITE for data sources and workbooks to add with add_sources: each hit has its `luid` and `in_graph`.

List semantic contexts: the business statements (definitions, rules, caveats) attached to the graph. Includes user-managed (SEMANTIC_CONTEXT, editable) and Tableau-managed (SEMANTIC_CONTEXT_EXTERNAL, read-only) contexts. - With `node` (an id or a description): only the contexts attached to that node. - Without `node`: every context on the graph; `is_global` true = only graph-wide contexts, false = only node-attached ones, omitted = both. The API doesn't filter by text yet; to find statements by meaning, use search_nodes.

Graph-health report: a 0-100 `health_score`, coverage metrics (e.g. how many nodes carry semantic context), graph stats, and concrete improvement suggestions (each with severity, recommended_action and the target node ids), grouped by category and topic. `pds_id` scopes the report to one published data source's subtree. `severity` ("high", "medium", "low"), `suggestion_type` and `limit` (default 20; a busy graph has hundreds) filter only the suggestion lists; the score, metrics and `summary` totals always cover the full (or PDS-scoped) graph.

WRITE: attach business context (one or more statements, 5-1000 characters each) to the knowledge graph, e.g. "Net Sales excludes returns and is reported in EUR." Set exactly ONE of: `target_node_id` (an exact node id from search_nodes/get_node; the context then DESCRIBES that node) or `is_global=true` (applies to the whole graph). CONNECTION, SITE, SCHEMA and semantic-context nodes can't be targets. Some sites accept only graph-wide context through the API (error node_semantic_context_disabled): then use is_global=true and name the field or data source in each statement. `name` is optional (derived when omitted). Needs the Creator role. Returns the new context, with its id.

WRITE: change a user-managed semantic context (`ctx_id`, e.g. "semctx:<uuid>"). Only what you pass changes. - `statements` REPLACES the whole stored set (include every statement you want to keep). - `name` renames it. - `attach_to` (an exact node id) re-attaches it to that node; `make_global=true` detaches it and makes it graph-wide. Not both. Tableau-managed (SEMANTIC_CONTEXT_EXTERNAL) contexts can't be changed. Needs the Creator role.

WRITE: delete a user-managed semantic context and its statements. Only semantic contexts created through Tableau Knowledge can be deleted; ids of other nodes are ignored, and Tableau-managed (SEMANTIC_CONTEXT_EXTERNAL) contexts are refused. Returns what was deleted (name and statements, so it can be recreated if needed). Deleting an id that doesn't exist succeeds without effect. Needs the Creator role.

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.

WRITE: add published data sources (`pds_luids`) and/or workbooks (`workbook_luids`) to a knowledge graph. Tableau ingests them in the background (seconds to minutes); check with list_sources (`ingest.status`). Adds only: sources already in the graph stay, and re-adding one re-ingests it. Exact LUIDs only, never names: find them with list_sources(site_search="part of a name"). `graph_id` is required (or TABLEAU_KNOWLEDGE_GRAPH_ID): this never falls back to the primary graph. Confirm the list with the user first. Uses Tableau Knowledge's undocumented web-app API, which can change without notice.

WRITE: remove published data sources and/or workbooks, and the nodes built from them, from a knowledge graph. The Tableau content itself is untouched. Context attached to removed nodes may be lost; graph-wide context stays. Exact LUIDs only (a source's properties.luid from list_sources); pass them in either list, the type comes from the graph. LUIDs that aren't in the graph are reported and skipped. `graph_id` is required (or TABLEAU_KNOWLEDGE_GRAPH_ID). Confirm with the user first. Returns what was removed; add_sources with the same LUIDs puts it back. Uses Tableau Knowledge's undocumented web-app API, which can change without notice.

WRITE: create a new, empty knowledge graph on the site (sites allow a few: see server_info `features.max_graphs_per_site`). Then fill it with add_sources. Returns the graph with its id. Confirm the name with the user first. Uses Tableau Knowledge's undocumented web-app API, which can change without notice.

WRITE: rename a knowledge graph, replace its description, and/or make it the site's primary graph (the default for everyone who doesn't pick a graph; only one graph is primary). Only what you pass changes. `graph_id` is an exact id from server_info. Confirm with the user first. Uses Tableau Knowledge's undocumented web-app API, which can change without notice.

Ask Tableau's own agent (the chat in Tableau Knowledge) a question about a graph and get its answer, e.g. to test semantic context and Business Preferences against an answer key: ask one question at a time and compare the numbers yourself. Pass the returned `conversation_id` to ask a follow-up in the same conversation (this server keeps the history in memory, so it lasts until the server restarts). Omit it for a fresh conversation, which is the fair way to test. `tools_used` lists the agent's own tool calls. The agent can also write semantic statements when asked to, so phrase questions as questions. Can take a minute. Uses Tableau Knowledge's undocumented web-app API, which can change without notice.

Export a published data source's semantic model to Apache Ossie (formerly OSI) YAML, the vendor-neutral format that Snowflake, dbt, Power BI, Databricks, Tableau Next and other tools convert from. Returns `ossie` (the YAML text, to save as `file_name`), `summary`, `validation` and `losses` (what could not be carried and what to fix by hand). `datasource` is a PDS id (from list_sources) or a description of it. Logical tables become datasets, fields become fields, row-level calcs become fields and aggregate calcs become metrics; every calc keeps its Tableau formula and gains portable SQL when the translation is exact. Semantic-context statements become ai_context. `default_aggregation_metrics` also turns each measure's Tableau default aggregation into a metric (total_sales = SUM(sales)). Always read `losses`: Tableau Knowledge has no physical table paths or join keys, so `source` and `relationships` need filling in before the model is used elsewhere. See ossie_guide.

Validate an Apache Ossie (formerly OSI) model, given as YAML or JSON text, against the official JSON Schema (0.2.0.dev0, bundled) and the spec's semantic rules: duplicate names, keys and relationship columns that are not declared fields, unknown datasets, qualified names in dataset-scoped metrics. 0.1.1 documents (`semantic_model:` list) are converted first; pass `model_name` when one holds several models. Runs locally: nothing is sent to Tableau.

Bring the business meaning of an Apache Ossie (formerly OSI) model into Tableau Knowledge as semantic contexts. WRITES only when `apply` is true; by default it returns the PLAN. `document` is the model as YAML or JSON text. Elements are matched to nodes of one published data source: models exported by export_to_ossie map back by their stored ids; other models need `target_datasource_id` (an exact PDS id from list_sources) and match by name. Each matched node gets one context named `ossie:<model>` holding its description, ai_context instructions, synonyms ("Also known as: ..."), example questions, metric definition (`include_definitions`) and relationships. Re-importing updates those contexts instead of duplicating them. `scope`: "auto" (default) attaches contexts to nodes and, on sites that accept only graph-wide context through the API (error node_semantic_context_disabled), writes the plan's `global_fallback` instead: one global `ossie:<model>` context whose statements are prefixed with what they describe. "node" never falls back; "global" plans the global context directly. Workflow: call without `apply`, show the user the operations (create/update/unchanged) and `unmatched` list, then call again with `apply=true` once they agree. Needs the Creator role.

Reference for Apache Ossie (formerly Open Semantic Interchange, OSI), the open standard for semantic models: what it is and its versions, the object model and rules, expressions and dialects, how Tableau maps onto it, relationships, ai_context, extensions, validation, the converters for other platforms (with exact commands), and a porting playbook with pitfalls. Read it before hand-editing a model or advising on a port. `topic` is one of: overview, model, expressions, tableau, relationships, ai_context, extensions, validation, converters, porting; omit it for everything.

Check a Tableau Business Preferences file (the "# rule" lines Tableau's agent reads before it answers) so every line is one the agent will actually follow. Call it with no `text` first to get the rulebook: format, limits, wording rules, workbook preparation and how to test. Checks: the "# " line format (a slip makes Tableau silently ignore the line), the limits (Tableau Cloud: 50 rules and 8,000 characters per dashboard; Tableau Next: 30,000 per semantic model), headers, duplicates, contradictions, thresholds without "use only this value", formatting rules that would leak into queries, conversational lines, absences that can be over-read, ambiguous ordering and averages, and missing baseline rules (query formatting, failure handling). `target` (a dashboard, sheet, workbook or data source: id or description) also checks every [Field] and "Field" the file names against the captions the agent will see in Tableau Knowledge, with "did you mean" suggestions, and flags workbook problems (duplicate, generic or helper field names). `product` is "cloud" or "next". Returns `ok` (no errors), `issues` by line, and stats.