list_generationsUse to find an earlier Generate run (to check, preview or save it): the recent runs with status, prompt and whether a render exists, newest first. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description | Default |
|---|---|---|---|
| runs | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / runs / items / properties / createdAt / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / runs / items / properties / createdAt / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / runs / items / properties / prompt / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / runs / items / properties / prompt / typeAdded value: +[
+ "string",
+ "null"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces read-only behavior. It adds useful behavioral detail beyond annotations: results include status, prompt, render existence, and are ordered newest first. This is enough transparency for a non-destructive list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence front-loads the use case, then lists return contents and ordering, capped with 'Read-only.' Every word earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has one optional parameter, a full output schema, and strong annotations. The description covers purpose, returned fields, ordering, and read-only behavior, so nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. The schema itself provides default, min, and max, but the description does not compensate for the low coverage or explain how limit affects the returned run list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'find an earlier Generate run' and describes exactly what is returned (status, prompt, render existence, newest first). It clearly distinguishes this list operation from sibling tools like get_generation_status or get_generation_preview by framing it as a discovery step before preview/save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use when you need to locate an earlier Generate run to check, preview, or save it. It does not explicitly name alternatives or state when not to use it, but the intended use is evident and sufficient for this simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target distinct resources, but several overlapping pairs exist: search/list_projects both find projects by title, fetch/get_project both return project details, and upload_logo_image/request_logo_image_upload are two upload paths. The descriptions help clarify boundaries, but an agent could still misselect.
Tool names overwhelmingly follow a clear verb_noun snake_case pattern (create_, list_, get_, update_, delete_). Minor deviations like bare 'fetch' and 'search', plus the mixed '3d' in generate_3d_model vs '3D' in descriptions, keep it from being perfectly consistent.
At 31 tools, this exceeds the 25+ threshold where agent tool selection becomes cognitively heavy. While the server covers a broad platform, several tools are near-redundant and could be consolidated, making the count feel inflated.
The surface covers project lifecycle, sharing/publishing, AI generation, uploads, materials, and account/plan management quite thoroughly. Minor gaps exist, such as no direct create_coin_project tool and no deletion for generation runs, but these are workable.