Skip to main content
Glama
Sign In
Sync MCP Server

Sync MCP Server

Official
by synchronicity-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

read project history

projects_list-generations
Read-only

Lists generations in an accessible project after checking access; set a limit to retrieve newest-first pages of that project's generation history.

Instructions

List the generations in one sync. project you can access, after first checking your access to that project. Use it for a project's history; for the whole organization, or without a projectId, use generations_list, and for one generation whose id you have use generations_get. A missing or inaccessible project fails with an error instead of returning an empty list. Always pass limit to get newest first; without it every generation in the project 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 (outputUrl is a deprecated alias with the same value), 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.
projectIdYesProject whose history to read (UUID), from projects_list or projects_create.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.4
    • changedInput schema / properties / projectId / description
      Previous value: -"Project whose history to read, from projects_list."New value: +"Project whose history to read (UUID), from projects_list or projects_create."
    • changedInput schema / properties / status / description
      Previous value: -"Filter generations by status"New value: +"Only generations in this status: PENDING, PROCESSING, COMPLETED, FAILED or REJECTED."
  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: +"Project whose history to read, from projects_list."
  3. Addedv0.1.5

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the readOnly/non-destructive annotations, the description discloses that a missing or inaccessible project fails with an error rather than an empty list, and that omitting limit returns everything unpaged in no guaranteed order — non-obvious behaviors an agent must plan around. It also enumerates the return shape, which matters since there is no output schema. It stops short of noting rate limits or maximum page behavior beyond what the schema states.

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 purpose and sibling routing, then paging rules, then return shape — a sensible priority order. It is dense and the final field enumeration runs long, but each clause carries information the agent needs given no output schema.

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?

Covers purpose, alternatives, failure mode, ordering, pagination contract, and the per-entry fields including the deprecated outputUrl alias — everything an agent needs for a 4-parameter read tool with no output schema. Nothing material 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, but the description adds real meaning: the consequence of omitting limit (unpaged, unordered, full result set) and the cursor contract (last returned id, paired with the same limit). It does not explain the status filter, though the schema already enumerates its values.

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 the generations in one sync. project') scoped to a single project, and immediately names the two siblings it must not be confused with (generations_list for org-wide/without projectId, generations_get for a known id). An agent can distinguish all three without opening a 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?

Explicit routing: use this for a project's history, generations_list for the whole organization or when no projectId is available, generations_get for a single known id. It also gives operational guidance to always pass limit for newest-first ordering and to page by passing the last returned id as cursor with 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