mcp-server-sigma

Workbooks List Report Lineage

workbooks_list_report_lineage

Read-only

List lineage for a report.

Instructions

List lineage for a report.

Follows Sigma's pagination to the last page and returns the keys of Sigma's page: entries from every page and nextPageToken null, since every page is read.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "report_id": "<report_id>"
    },
    "name": "workbooks_list_report_lineage"
  }
}

Input Schema

Name	Required	Description	Default
`report_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.4Oct 17, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and non-destructive behavior. The description adds non-obvious behavior beyond the annotations: it automatically follows Sigma pagination to the last page and returns aggregated 'entries' with a null 'nextPageToken'. It omits permission or failure-mode details, but the added pagination contract is valuable.

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?

Two tightly written sentences, front-loaded with the purpose and followed by the pagination contract. Every sentence earns its place with no redundant restatement of 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 and annotations cover safety behavior, so the description need not explain return structure generically; it nevertheless explains the auto-pagination return shape. The remaining gaps are report_id semantics and sibling differentiation, which prevent a perfect score.

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

Parameters2/5

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

The sole parameter report_id has 0% schema description coverage, so the description must compensate. It only says 'for a report' and does not explain the expected ID format, where to obtain it, or any constraints, leaving a meaningful gap.

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

Purpose4/5

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

The description states a specific verb and resource: 'List lineage for a report.' It is clear what the tool does, but it does not distinguish itself from sibling lineage tools such as workbooks_list_workbook_lineage or elements_list_element_lineage.

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

Usage Guidelines3/5

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

Usage is only implied by the name and first sentence. There is no explicit guidance on when to use this versus other lineage endpoints, nor any prerequisite or exclusion noted.

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

Deploy Server