Tableau Knowledge MCP

Overview Schema Source Related Servers Discussions Admin

Import from Ossie

import_from_ossie

DestructiveIdempotent

Imports Apache Ossie (OSI) model descriptions, synonyms, metrics, and relationships into Tableau Knowledge semantic contexts; previews a plan by default and writes only when apply is true.

Instructions

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.

Input Schema

Name	Required	Default
`apply`	No
`scope`	No	auto
`document`	Yes
`graph_id`	No
`model_name`	No
`include_definitions`	No
`target_datasource_id`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Oct 31, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds substantial context beyond annotations: dry-run default, the `node_semantic_context_disabled` fallback path, and explicit confirmation that re-import updates rather than duplicates contexts (supporting idempotentHint). It does not spell out what happens to existing context statements that the new model no longer contains — a gap for a tool flagged destructiveHint=true.

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 purpose and the read/write gate before the detail, and each paragraph maps to a decision the agent must make. It is on the long side and the `scope` sentence is dense, but no sentence is filler.

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

Completeness5/5

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

For a 7-parameter, destructive, open-world import with an output schema, the description covers the mutation gate, matching strategy, fallback behavior, permissions, and the human-approval loop. Return-value detail can be deferred to the output schema.

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 carries the load, and it explains `document` (YAML or JSON text), `apply` (write gate), `scope` with all three values and their fallback behavior, `target_datasource_id` (exact PDS id from list_sources), and `include_definitions`; `model_name` is only implicitly covered via the `ossie:<model>` naming and `graph_id` is never mentioned.

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: importing an Apache Ossie model's business meaning into Tableau Knowledge as semantic contexts. The inverse relationship to `export_to_ossie` and the contrast with `validate_ossie`/`ossie_guide` are clear enough that an agent can pick this tool without opening sibling schemas.

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

Usage Guidelines5/5

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

Gives an explicit two-step workflow (call dry to get the PLAN, show create/update/unchanged and `unmatched`, then re-call with `apply=true` after user agreement), plus the prerequisite (Creator role) and the conditional requirement for `target_datasource_id` when the model wasn't exported by `export_to_ossie`.

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