Skip to main content
Glama
mcp-server-sigma

mcp-server-sigma

Elements List Workbook Page Elements

elements_list_workbook_page_elements
Read-only

List elements on a specific page of a workbook.

Instructions

List elements on a specific page of a workbook.

Follows Sigma's pagination to the last page and returns the keys of Sigma's page: entries from every page, total when Sigma sends it (Sigma's value), and nextPage null (hasMore false where Sigma sends it) since every page is read.

Input Schema

NameRequiredDescriptionDefault
page_idYes
workbook_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.4

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the readOnlyHint/destructiveHint annotations, the description discloses the key behavioral trait: it transparently paginates through every Sigma page and returns entries aggregated across pages, with nextPage null and hasMore false. That tells an agent it never needs to page manually — valuable and non-obvious.

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?

Two sentences, purpose front-loaded, followed by the pagination contract. The parenthetical about which keys come from Sigma is dense but carries real information; it is somewhat redundant against the output 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?

For a two-parameter read tool with an output schema and safety annotations, the description covers what it does and how pagination behaves. The remaining gap is operational: no pointer to how page_id is discovered and no note on entry ordering.

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

Parameters3/5

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

Schema coverage is 0% for the two required parameters, so the description must compensate. It establishes the workbook/page relationship, but neither workbook_id nor page_id is explained (format, source, or how to discover a page_id). The parameter names are largely self-evident, which keeps this at minimum-viable rather than deficient.

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 with a clear scope qualifier: list elements on a specific page of a workbook. That distinguishes it implicitly from elements_list_workbook_elements (whole workbook), but it never names or contrasts any sibling explicitly.

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?

The scoping phrase 'on a specific page of a workbook' implies when this tool is the right choice, but there is no explicit when-to-use guidance, no mention of the workbook-wide alternative, and no note on how to obtain a page_id (e.g. via workbooks_list_workbook_pages).

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