Skip to main content
Glama
logisky

logisheets-mcp

create_pivot

Build a pivot table from a source block: choose row and column fields, aggregate a measure with SUM, COUNT, AVERAGE, etc., and get an addressable result block for further calculations.

Instructions

Cross-tabulate a table: one row per distinct value of rows, one column per distinct value of columns, each cell aggregating measure.

The result is an ordinary block, so every cell is addressable: BLOCKREF("<name>", "<a rows value>", "<a columns value>"). That is what lets you put one number from it in a sentence or feed it to another calculation.

You declare the recipe; the engine generates every cell from it. Do not write formulas, and do not write into the block — renaming a field of the source rebuilds the pivot rather than breaking it, which is only true because nothing is hand-written.

rows and columns must be fields whose values REPEAT (a region, a quarter, a status). Pointing either at an id gives one row per record, which is the source table again, not a pivot.

IMPORTANT: a pivot's numbers are live but its SHAPE is not. When new values appear in the source, its rows and columns fall behind while every number in it stays correct — call build__refresh_pivot. describe_block reports when that has happened.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
funcNoHow to aggregate. Defaults to SUM. COUNT counts matching RECORDS and ignores `measure`; COUNTA counts the records whose `measure` is filled in, which is how you ask how complete a column is.
nameNoRef name for the new block. Defaults to "<source>_pivot".
rowsYesField of the source whose distinct values become the ROWS. Its values must repeat.
orderNoOrder of the rows. `ascending` (default) sorts; `firstSeen` keeps the source's own sequence; `custom` uses `order_values`.
sourceYesRef name of the table to pivot.
columnsNoField whose distinct values become the COLUMNS. Omit for a simple group-by with one value column.
filtersNoWhich source records count at all. Omit to count every one. Applied to the rows AND the numbers, so a group left with no records gets no row rather than a row reading 0.
measureYesField being aggregated. Normally a number field.
row_totalNoName for a column totalling each row across EVERY value of `columns` — e.g. "Total". Omit for no total column.
order_valuesNoThe row sequence for `order: custom`. A value you omit is placed after the listed ones, never hidden.
extra_measuresNoExtra columns with their own function and measure, for showing more than one number per group.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries the burden of behavioral disclosure. It does so richly: the result is an ordinary block with addressable cells, renaming a source field rebuilds the pivot, numbers are live but the shape is not, and describe_block reports staleness. This goes well beyond the annotations and reveals genuine quirks an agent must know.

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?

The description is longer than average, but each paragraph earns its place: core definition, cell addressability, the no-write constraint, field cardinality caution, and the staleness warning. It is front-loaded with the essential cross-tabulation definition. Slight verbosity around the 'declare the recipe' analogy could be tightened without loss.

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 complex 11-parameter creation tool with no output schema, the description covers behavior, constraints, result type, and follow-up actions. The main gaps are not explaining what happens if the source is missing and the inconsistent refresh tool name. Overall, an agent has enough context to call it correctly and know what to expect.

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 100%, so the baseline is 3. The description adds value beyond the schema by explaining the conceptual consequences of pointing rows/columns at IDs: 'gives one row per record, which is the source table again, not a pivot.' It also clarifies the live-numbers/static-shape behavior tied to the generated result. Minor but meaningful extra meaning.

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?

The description opens with a precise definition: 'Cross-tabulate a table: one row per distinct value of `rows`, one column per distinct value of `columns`, each cell aggregating `measure`.' It clearly differentiates creation from the edit/refresh operations by explaining the generated recipe model and explicitly warning against writing formulas or writing into the block.

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 description gives strong contextual guidance: use repeating fields for rows/columns, avoid ids, and call a refresh tool when the shape falls behind. However, it refers to 'build__refresh_pivot' while the sibling list contains 'refresh_pivot', creating a potential invocation mismatch. It also never explicitly contrasts this tool with edit_pivot, so an agent gets no direct guidance on when to prefer creation over editing.

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