Skip to main content
Glama
This connector has been deprecated

Duplicate listing of the same server under an old namespace. The maintained listing is Layero (ru.layero/layero): same endpoint https://mcp.layero.ru/mcp, current description and tools. The landing-page generator described here was removed in MCP 2.0.

Настройки сборки проекта

project_settings
Destructive

Build settings of a project: read them, or change them without the dashboard — the way out when detection guessed wrong (wrong folder, wrong type, wrong command).

`get` returns `settings` (what is saved on the project; null — not set,
the platform decides), `resolved` (what the next build will actually use,
per field: `value`, `source`, `policy`) and `last_build` (what the latest
ready build was really built with). Precedence is `layero.json` in the
repository > project settings > detection > framework default: a field
with `policy: "locked_by_file"` is set by `layero.json`, and changing the
project setting will not change the build — edit the file instead.

`update` CHANGES HOW THE PROJECT IS BUILT — ask the person first unless
they asked for exactly this change. Prefer `layero.json` in the repository
for anything that should live with the code; use this tool for what the
file cannot hold (`root_directory`, `project_type`) and for projects you
cannot push to. Nothing is rebuilt by the update itself: apply it with
`retry_deploy(redeploy=true)` or a push.

Input Schema

NameRequiredDescriptionDefault
portNoContainer apps: the port the app listens on. `0` resets to the default.
badgeNoThe «Made with Layero» badge at the bottom of the site's pages. `false` hides it — on the Pro plan only; takes effect with the next deploy.
actionNo`get` — show the build settings and what they resolve to. `update` — change the settings passed in the other arguments; arguments you omit stay as they are.get
projectYesThe 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.
frameworkNoFramework preset for a static build: `vite`, `nextjs`, `astro`, `generic`, `static` …
force_typeNoSet `project_type` even though the platform detected another type.
node_versionNoNode major, e.g. `22`. `""` resets to auto-detection.
project_typeNoHow the project runs: `spa` — static files (any static framework); the others — an app in a container. The platform checks the repository and may object (409): then re-read the objection and pass `force_type=true` only if the person insists.
build_commandNoBuild command, whole: `npm run build`.
start_commandNoContainer apps: start command, listening on `0.0.0.0` and `$PORT`. `""` resets to detection by entry point.
root_directoryNoApp folder inside the repository (`apps/web`). `""` resets to the repository root. Changing it clears the detected framework and commands of the old folder.
install_commandNoInstall command. `""` resets to auto-detection by lockfile.
package_managerNoPackage manager override.
output_directoryNoFolder that holds `index.html` AFTER the build (`dist`, `build`, `dist/client`).

Output Schema

NameRequiredDescriptionDefault
changedNo
projectYes
resolvedNo
settingsYes
last_buildNo
next_actionYes
project_typeYes
layero_json_warningsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / badge
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "The «Made with Layero» badge at the bottom of the site's pages. `false` hides it — on the Pro plan only; takes effect with the next deploy.",
      +  "title": "Badge"
      +}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say destructiveHint=true; the description goes well beyond: updates change the build, nothing is rebuilt by the update itself and must be applied via `retry_deploy(redeploy=true)` or a push, `update` is partial (omitted args persist), a 409 can come back from repository checks, and `policy: "locked_by_file"` means changing the setting has no effect. That is exactly the operational context annotations cannot express.

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 and organized into three coherent blocks: return shape, precedence, then the mutation warning. Slightly longer than strictly necessary — the parenthetical 'wrong folder, wrong type, wrong command' and some backtick-heavy phrasing could be trimmed — but every paragraph carries decision-relevant content.

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 14-parameter, dual-action, destructive-by-annotation tool, the description covers action semantics, return shape (`settings` / `resolved` / `last_build`), precedence and lock behavior, the 409/force_type path, and the deploy follow-up. Nothing needed to call it safely is missing, and the output schema is not merely re-stated.

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 baseline is 3; the description adds real interpretive value on top by explaining the precedence chain (`layero.json` > project settings > detection > framework default) and the `policy`/`locked_by_file` semantics that determine whether a given parameter will actually take effect. It does not add per-parameter syntax beyond the schema, so not a 5.

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?

Opening line names the specific resource (build settings of a project) and both verbs (read / change), and the `get`/`update` split is spelled out immediately after. The agent knows this is the build-config tool, not the env-var, domain, or deploy tool, without opening the 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 alternatives and exclusions: prefer `layero.json` for anything living with the code, use this tool for what the file cannot hold (`root_directory`, `project_type`) or for repos you cannot push to. It also states a prerequisite behavioral rule — ask the person before `update` — and that pre-change detection mistakes are the canonical trigger.

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.

Resources