Skip to main content
Glama

List Calculations

list_calculations
Read-onlyIdempotent

List this organization's calculations, newest first, each with its status, lot size, unit cost and offer price. Use it to find calculations started outside this conversation, such as the ones a person starts on the upload page (upload_session_id set to the link's upload_session_id lists exactly those), or to check many at once (ids, up to 500). Filter by status, part or batch. Page with cursor until has_more is false. For one calculation in full, use get_calculation. Read-only and free.

Input Schema

NameRequiredDescriptionDefault
idsNoComma-separated calculation IDs (max 500). THE polling surface for bulk clients: one weight-1 sweep returns the status of every listed calculation, instead of N weight-1 detail requests that exhaust the per-org rate budget (self-DoS). When set, `limit` and ordering are ignored and every matching row is returned.
sortNoOrdering key. Rows with no value yet (an in-flight run has no unit cost) sort last in both directions. Ignored when `ids` is set. `offer_price` orders on the price each calculation headlines and the comparison ranks on (the item's `offer_price`; an assembly priced only in part states none and sorts last); `unit_cost` on the unit cost (direct cost plus the flat overheads, below the cost-sheet rungs). `created_at`, `offer_price`, `lot_size` and `annual_volume` support `cursor`; `unit_cost` and `finished_at` are null until a run settles, so a cursor over them cannot reach every row and is rejected — those two return the first page only.created_at
limitNoMaximum rows to return in one page.
orderNoSort direction over the collection's ordering key. Use `asc` to reconcile a batch: rows come oldest-first, so work created while you page lands after your position instead of shifting rows under it.desc
cursorNoOpaque position token from the previous page's `next_cursor` (or the `Link` / `X-Next-Cursor` response header). Omit it for the first page. Keep every other query parameter identical for the whole walk — a cursor replayed against different filters is rejected.
part_idNoOnly the calculations of this part, by its id (part_id on any calculation).
batch_idNoNarrow to one batch's calculations — e.g. every cell of a multi-environment comparison grid. Pair with the batch comparison endpoint, which returns the pivoted matrix.
created_afterNoOnly rows created at or after this instant (RFC 3339, e.g. `2026-07-20T09:00:00Z`). Inclusive.
include_totalNoAlso return the total number of rows matching the query, across all pages. Off by default because it costs an extra scan; `has_more` is the cheap way to know whether to keep paging.
status_filterNoFilter by lifecycle status (e.g. queued, running, succeeded, failed, cancelled). Repeatable; several values are OR-ed.
created_beforeNoOnly rows created strictly before this instant (RFC 3339). Exclusive, so an `after`/`before` pair tiles a range without overlap.
include_facetsNoAlso return `facets`: status and material values with counts, each computed over everything the OTHER active filters allow.
material_grade_idNoOnly runs priced against one of these material grades. Repeatable; several values are OR-ed, so passing every value is the same as passing none.
upload_session_idNoOnly the calculations created through one upload link, by the `upload_session_id` the link was issued with — the parts a person uploaded on its page, and no one else's.
include_componentsNoWith `part_id`: also list the calculations this part received as a component of an assembly (each at the lot the assembly implied). Ignored without `part_id`.
parent_calculation_idNoOnly the component calculations of this assembly. By default the list contains top-level calculations only — assembly components are reachable through their parent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / limit / maximum
      Added value: +500
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / sort / description
      Previous value: -"Ordering key. Rows with no value yet (an in-flight run has no unit cost) sort last in both directions. Ignored when `ids` is set. `offer_price` orders on the price each calculation headlines and the comparison ranks on (the item's `offer_price`; an assembly priced only in part states none and sorts last); `unit_cost` on the unit cost (direct cost plus the flat overheads, below the cost-sheet rungs). `created_at`, `lot_size` and `annual_volume` support `cursor`; `unit_cost`, `offer_price` and `finished_at` are null until a run settles, so a cursor over them cannot reach every row and is rejected — those three return the first page only."New value: +"Ordering key. Rows with no value yet (an in-flight run has no unit cost) sort last in both directions. Ignored when `ids` is set. `offer_price` orders on the price each calculation headlines and the comparison ranks on (the item's `offer_price`; an assembly priced only in part states none and sorts last); `unit_cost` on the unit cost (direct cost plus the flat overheads, below the cost-sheet rungs). `created_at`, `offer_price`, `lot_size` and `annual_volume` support `cursor`; `unit_cost` and `finished_at` are null until a run settles, so a cursor over them cannot reach every row and is rejected — those two return the first page only."
    • addedInput schema / properties / upload_session_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "format": "uuid",
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Only the calculations created through one upload link, by the `upload_session_id` the link was issued with — the parts a person uploaded on its page, and no one else's.",
      +  "title": "Upload Session Id"
      +}
  2. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed1 schema field changed
    • addedInput schema / properties / part_id / description
      Added value: +"Only the calculations of this part, by its id (part_id on any calculation)."
  4. Added

TDQS

A4.3/5.0
Behavior4/5

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so safety is covered. The description adds non-annotation context: that the call is 'free' (no quota cost) and that results come back newest-first by default with cursor-based paging. It does not, however, describe the free/paid distinction in more detail, nor the failure modes when a cursor is replayed against changed filters.

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-loaded with what is listed and in what order, then usage, filtering, paging and the alternative — a sensible priority order. It is dense but nearly every clause carries information; the nested parenthetical about upload_session_id is slightly convoluted to parse but still short.

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?

With 16 optional parameters and no output schema, the description covers the returned shape at a high level (status, lot size, unit cost, offer price) and the paging contract, which is what an agent needs to iterate. It omits mention of several parameters (facets, include_total, created_after/before, parent_calculation_id), but those are fully documented in the schema, so the description is adequate for correct invocation.

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 description coverage is 100% and the parameter descriptions are exceptionally rich (ids polling guidance, cursor consistency rules, sort/cursor compatibility). The description's own parameter mention ('ids, up to 500', 'filter by status, part or batch') merely restates a fraction of what the schema already documents, so it adds no meaningful semantics beyond the structured fields. Baseline 3 is correct.

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 ('List this organization's calculations'), the default ordering ('newest first'), and the fields returned ('status, lot size, unit cost and offer price'). It also explicitly distinguishes itself from get_calculation, so an agent can choose between them without opening either schema.

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 concrete use cases (finding calculations started outside the conversation, bulk status checks via ids up to 500), names the sibling alternative for the single-record case ('For one calculation in full, use get_calculation'), and states the paging termination condition ('until has_more is false'). This is explicit when/when-not/alternative guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.