Skip to main content
Glama
Sign In
Sync MCP Server

Sync MCP Server

Official
by synchronicity-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

list generations

generations_list
Read-only

List generations across your Sync organization to find a generation ID or check which jobs are still running. Filter by project or status, and paginate results with limit and cursor.

Instructions

List generations across the current sync. organization, from every member and API key, to find a generation id or see which are still running. For one known id use generations_get. Pass projectId to narrow to one project; projects_list-generations, when available, does the same but fails on a project you cannot access, while this tool returns an empty list. Always pass limit to get newest first; without it every matching generation comes back unpaged in no guaranteed order. For the next page pass the last returned id as cursor with the same limit. Each entry has id, status, model, createdAt, projectId, input, options, outputMediaUrl once COMPLETED, and error and errorCode on failure.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of generations to return (1-100). When set, results are ordered newest-first and can be paged with `cursor`.
cursorNoGeneration id to page after - pass the last id of the previous page. Only used together with `limit`.
statusNoOnly generations in this status: PENDING, PROCESSING, COMPLETED, FAILED or REJECTED. PENDING (queued) and PROCESSING both mean still running, so check both before concluding nothing is in progress.
projectIdNoOnly generations in this project, from projects_list or projects_create.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.4
    • changedInput schema / properties / status / description
      Previous value: -"Filter generations by status"New value: +"Only generations in this status: PENDING, PROCESSING, COMPLETED, FAILED or REJECTED. PENDING (queued) and PROCESSING both mean still running, so check both before concluding nothing is in progress."
  2. Changed1 schema field changed
    • changedInput schema / properties / projectId / description
      Previous value: -"Filter to a live project accessible to the session user or API-key owner. Inaccessible projects return an empty list."New value: +"Only generations in this project, from projects_list or projects_create."
  3. Addedv0.1.5

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare a safe read; the description adds real behavioral context beyond them: default behavior without limit is an unpaged, unordered full result set, paging requires cursor plus the same limit, and the accessible-project case degrades to an empty list rather than an error. It also enumerates the shape of each returned entry including conditional fields (outputMediaUrl only once COMPLETED, error/errorCode on failure).

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?

Dense but front-loaded: purpose first, then routing, then parameter behavior, then return shape. Every sentence carries information, though the single long paragraph could be split for scanability and there is a typo ('sync. organization').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by describing the per-entry fields and their conditional presence, and it covers the paging contract and the project-scoping edge case. Nothing an agent needs to call this correctly and interpret the response is missing.

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 coverage is 100%, so the baseline is 3, and the description earns above that by explaining the consequence of omitting limit (unordered, unpaged) and the coupling between cursor and limit. It does not restate the status enum values, leaving that correctly to the schema.

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 generations) plus the scope (across the current organization, every member and API key) and the two concrete reasons to call it: find a generation id or see which are still running. It explicitly names the sibling generations_get for the single-id case, so an agent can route 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?

Covers when to use it (browse/search ids, check running work), when not to (one known id → generations_get), and how it differs from the sibling projects_list-generations, including the important failure-mode difference (empty list vs. error on inaccessible project). It also gives prescriptive operational guidance: always pass limit, page with the last returned id plus the same limit.

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