Skip to main content
Glama
Sign In
Tableau Knowledge MCP

Tableau Knowledge MCP

by biztory
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Search graph nodes

search_nodes
Read-only

Find Tableau knowledge graph nodes by meaning rather than exact name, returning ranked matches with scores so you can locate data sources, sheets, fields, and dashboards by intent.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes
graph_idNo
scope_idNo
node_typeNo
thresholdNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare the read-only, non-destructive, open-world profile, so the description is not burdened with safety disclosure. It adds genuine value beyond that: ranked 0-1 scores, the semantic_statements field when a statement matched, and the threshold/limit filtering behavior. What remains unstated is pagination beyond limit and any latency or cost characteristics.

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

Conciseness5/5

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

Front-loaded with the core distinction (meaning, not exact name) before the reference detail. The bulleted parameter notes are dense and every sentence earns its place; nothing is padded or repeated from the schema.

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?

An output schema exists, yet the description still usefully flags the score field and semantic_statements, which are the fields an agent will actually act on. Combined with the tool-selection guidance and chaining advice, this is nearly complete for a search tool, with graph_id being the only meaningful omission.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry the load, and it does for four of six parameters: node_type (with the full valid value list), scope_id (with the PDS subtree semantics), limit range and default, and threshold semantics. query is self-evident, but graph_id is never mentioned in either the description or the schema, leaving one parameter fully opaque.

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 ('Find graph nodes') and immediately disambiguates the mechanism: semantic matching rather than exact-name lookup, with a concrete example ('revenue' matching 'Net Sales'). An agent can distinguish this from sibling tools like get_node or search_semantic_contexts 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?

Explains when to use it (finding nodes by meaning) and names the downstream siblings to chain into (get_node, list_edges, lineage, impact_analysis). It stops short of explicitly naming an alternative for exact-name lookup or stating when not to use this tool, so it is strong but not fully prescriptive.

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

Deploy Server

Other Tools