Layero

История сборок проекта

list_deploys

Read-onlyIdempotent

The project's latest builds: how each one ended, how long it took and which one is live now.

Use it to pick a target for `rollback` or `diagnose_deploy`. For "what is
up with the site right now" `site_status` is enough and cheaper.

Per build: `branch`, `source` (`git` — built on push, `cli` — an uploaded
folder), short `commit`, `created_at` / `started_at` / `finished_at`
(UTC), `queued_s` (wait in the queue) and `duration_s` (build time, null
while it is still running), `failure_stage` for failed ones, `is_active`
— the build now served on the canonical address.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>"
    },
    "name": "list_deploys"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	How many of the latest builds to return. Default 10, at most 50.
`project`	Yes	The project: its slug (`my-site`) or id, as listed by `my_projects`. The site address works too (`https://clear-garden-vypm.layero.app` or just `clear-garden-vypm`) — note that the address host is NOT always the slug.

Output Schema

Name	Required	Description	Default
`deploys`	Yes
`project`	Yes
`next_action`	Yes
`project_type`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedSep 18, 2026

changedInput schema / properties / limit / description

Previous value: -"Сколько последних сборок вернуть. По умолчанию 10."New value: +"How many of the latest builds to return. Default 10, at most 50."

changedInput schema / properties / project / description

Previous value: -"Проект: слаг (`my-site`) или id. Слаг — то, что видно в адресе сайта; если пользователь назвал сайт словами, возьми слаг из `my_projects`."New value: +"The project: its slug (`my-site`) or id, as listed by `my_projects`. The site address works too (`https://clear-garden-vypm.layero.app` or just `clear-garden-vypm`) — note that the address host is NOT always the slug."

addedOutput schema / $defs / DeployBrief / properties / commit

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Commit"
+}

addedOutput schema / $defs / DeployBrief / properties / duration_s

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Duration S"
+}

addedOutput schema / $defs / DeployBrief / properties / failure_stage

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Failure Stage"
+}

addedOutput schema / $defs / DeployBrief / properties / finished_at

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Finished At"
+}

addedOutput schema / $defs / DeployBrief / properties / queued_s

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Queued S"
+}

addedOutput schema / $defs / DeployBrief / properties / source

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Source"
+}

addedOutput schema / $defs / DeployBrief / properties / started_at

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Started At"
+}

AddedAug 3, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral details beyond that: the meaning of `source` (`git` vs `cli`), `duration_s` being null while running, `failure_stage` for failed builds, and `is_active` indicating the live build. It also notes timestamps are UTC. These details clarify the tool's behavior without repeating what annotations already say.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose first, then usage guidance, then field details. Every sentence contributes useful information, and the structure makes it easy to skim. It is longer than the simple examples but appropriately so given the richness of the return object.

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?

For a list operation with a comprehensive output schema, the description covers the essential context: what the tool returns, how to use it, and how it differs from related tools. It explains key edge cases like null duration and failure stages, and it references the output schema implicitly by detailing fields. Nothing critical for correct invocation is missing.

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%, so the baseline is 3. The description does not add additional meaning for the request parameters (`project` and `limit`); it focuses on the shape of each build object rather than the input parameters. The schema already fully documents the parameters' semantics, so the description adds no extra value here.

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 clear, specific statement: "The project's latest builds: how each one ended, how long it took and which one is live now." This identifies the verb (list), the resource (project builds), and the key outputs, distinguishing it from sibling tools like rollback and site_status.

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 usage guidance is provided: "Use it to pick a target for `rollback` or `diagnose_deploy`." It also gives a clear alternative: "For 'what is up with the site right now' `site_status` is enough and cheaper." This tells the agent exactly when to choose this tool over others.

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

All Layero tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.