Layero

Stop a build that is still running. The live address does not change — the previous version stays on it.

Mechanical errors of Russian typography — with the exact place and a replacement. This is CODE, not a model's judgement: the same text gives the same list of findings. It catches what the eye misses and the reader feels: non-breaking spaces, dashes, straight quotes, a dot instead of a comma in decimals, spaces around punctuation, double spaces. Every finding carries a ready replacement — apply it rather than rewriting the fragment your own way. WHAT IS NOT HERE. Plain style, sentence length, officialese, signs of AI slop — that is judgement, and it lives in the `layero://editorial/ru` resource. Read it when asked to "make the text better" rather than "fix the typography".

Check whether a connected domain has started working. Runs the DNS check immediately instead of waiting for the background re-check. If the records have not propagated yet, that is normal — say so and suggest coming back later.

Measure a site's speed and say whether it got worse after a deploy. The verdict comes FROM THE SCORE, not from timings: repeated runs of the same deploy vary by at most one point, while LCP and TTFB on identical code swing by 37-40%. A difference of 3 points or more is meaningful; anything smaller is measurement noise, and calling that a regression is inventing a problem. A run takes tens of seconds. With `wait=true` the tool waits for you; do not start a second measurement in parallel — it will occupy the queue and add nothing.

Connect Yandex Metrika to a site. IMPORTANT: authorisation happens IN A BROWSER, and neither you nor the platform can do that step for the user. The tool returns a link — show it and ask them to open it and grant access. Do not poll in a loop: the person may walk away for an hour. Check later through this same tool without the `branch` argument, or through `site_analytics`.

Connect a custom domain to a site. IMPORTANT: between this call and a working domain stands A PERSON. You get DNS records — show them to the user and explain they go in at their domain registrar. Do not wait for readiness: DNS propagates in minutes to an hour, the platform re-checks on its own, and you check later via `check_domain`. Spinning here burns time and context for nothing. The address can be passed as-is: the platform reduces `https://shop.example.com/page` to `shop.example.com` itself.

Who may call a method of a table or a function: shows the SQL and applies it after consent. OPENS DATA TO THE INTERNET. Call it without `apply` first: the platform returns the commands and warnings (for example "row-level security is off — a visitor will get every row"). Show them to the person. With apply=true a client with forms asks the person itself; without forms get consent in the chat and pass confirmed=true together with expected_sql from the preview. Methods you do not name keep their current level. Exactly the shown commands are applied: if the grants changed meanwhile, the platform refuses — show the new ones. Needs a token with the admin scope, for the preview too.

The database's Data API keys: list, issue, revoke. The list never contains key values. Issuing and revoking need the person's consent: a client with forms asks by itself; without forms ask in the chat and pass confirmed=true. The value of an issued key is returned once: the platform does not store secret keys. Hand it to the person for their server and do not repeat it afterwards. Revoking breaks everyone who uses the key — including the site, if the key is baked into its build (`in_build`). Issuing and revoking need a token with the admin scope.

The database's REST and RPC methods with an access level per HTTP method. The level says who may call the method: closed, visitor (any site visitor), user (signed-in people), server (the server only). It is read from the role grants in force in the database itself — exactly as the gateway sees them.

Sites allowed to call the database from a browser: list, add, remove. Addresses of the connected projects and their branches are allowed automatically — do not add them. An added site opens no data by itself: what can be read and written is decided by access levels. Adding and removing need the person's consent; a removed site is refused on every request. Needs a token with the admin scope.

A real request to a method through the gateway — as a visitor, a user or the server. The platform supplies the key and the token. Writes (POST, PATCH, DELETE, a function call) are rolled back: rows in the database do not change, but the rollback does not undo sequence numbers, calls from the database to the outside, session locks or the daily call quota. The answer is real: grants, row policies and refusals are the same the site will see. Needs a token with the admin scope.

Whether the database has the Data API enabled, its address, keys and the sites allowed to call it. Keys are shown as prefixes only: the platform never returns values and does not store secret ones. The API cannot be enabled with a tool: enabling gives the database a public address, and that is the person's decision in the dashboard.

Raw log lines — for when the `diagnose_deploy` analysis was not enough. Start with `diagnose_deploy`: it has already pulled out the cause and the neighbourhood of the fatal line. Come here when you need to look with your own eyes — the cause is vague, or you are interested in how the app behaves rather than in a failure. You get the TAIL. `truncated` says earlier lines were dropped; do not present the tail as the whole log. For build logs, package-manager network chatter is hidden BEFORE the tail is cut, so the tail holds meaningful lines; `noise_hidden` says how many were hidden and `include_noise=true` shows them.

Why a deploy failed — with the cause parsed out, not a raw log. Without `deploy` the latest build is used; that is what reflects the current state. To examine a specific older one, pass its id. The response is not a log tail but the neighbourhood of the fatal line: the platform has already picked out what matters. Read `verdict` and the summary, fix the code, deploy again — you close this loop yourself, without involving the person. `build_facts` — how it was built: `project_type`, `framework`, `node_version`, `package_manager`, `install`, `build`, `output` (each with its origin in parentheses: default, auto-detected, layero.json, dashboard …), `source` (`git` / `cli`), `root_directory`, `queued_s`, `duration_s`. Apps built into a container (`node_web`, `python_web`, `ssr_next`, full-stack) also get `runtime_kind`, `start` (the start command), `port`, `env` and, for full-stack, `fullstack` / `fullstack_frontend`. A value marked `(as built)` is the platform's record of this very build; `(current settings: …)` is what the project settings resolve to now, not a fact about this build. A missing key means the platform did not report that fact — on a failed build often because it did not get that far, on a `ready` build it just is not recorded (static builds print more than container builds); it is not a sign of a problem. `sources_note` appears when a value is marked `(from dashboard)` / `(from hint)`: that is «saved in the project settings», by a person or by import-time detection — the platform does not record which. `candidate_app_dirs` is filled when the builder found several app folders in a monorepo and needs a `root_directory`. Three log excerpts, all untrusted: `build_log_excerpt` — the build itself; `launch_log_excerpt` — the platform's lines about starting the app after the build (container launch, readiness probe, wake-ups), empty for static sit…

Project environment variables: list names, set them, remove them. VALUES ARE NEVER READ BACK — not by you, not by the platform in its response. Only names and lengths are returned. This is a deliberate rule rather than an implementation limit: anything that reaches your answer settles into the conversation history, and a secret that lands there cannot be taken back. If the user asks "what is my key", say plainly that you cannot show it and offer to set a new one. `set` does not require knowing the other variables — the platform keeps them. `unset` removes only the named ones. A change needs a new deploy: variables are picked up at build time, not on the fly. Say so, or the user will think nothing happened.

Create a Layero project from a repository — path (a) without the dashboard. From then on a push to the branch is a preview, a push to the production branch is production. After the link the tool finishes the setup wizard itself and starts the first build; `setup` in the result says whether that happened. Detected values are NOT written into the project settings: the builder detects the framework, build command and output folder from the repository on every build, so a later change in the repository is picked up. Only a decision is pinned — the app folder of a monorepo and the package manager named in `layero.json`. Until 2.1.1 the project stayed in `pending_setup` while the answer promised a build that never started. Two shapes, same as the CLI: GitHub goes through the App installation (project and webhook in one call); other providers create the project first and then connect the source — that step reports whether the webhook could be registered. If the provider is not connected, the result says `needs_connection` with the dashboard address: the person connects the token there, never through the chat. Monorepo: one project builds one app folder — pass `root_directory`. Several apps in one repository are several projects, one call each, with different `root_directory` and `name`. If the repository is already linked and the call would duplicate an existing project (same folder, or no `root_directory` given), nothing is created: the result is `already_linked` with `linked_projects` — slug, url, root_directory and branch of every project built from this repository. On `created`, `linked_projects` lists the OTHER projects already built from the same repository; `linked_projects_checked: true` says the check was made, so an empty list means there are none (`my_projects(repo=…)` answers the same question later). When the root has no app and detection sees a…

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.

The project's own domains and their state.

The project's environments — one per branch (or the single `cli` one), each with its address and the state of its latest build. Answers "where is the preview of my branch" and "what is on production now". `url` is the environment's own address (its host ends with `-<branch>`); the production branch is ALSO served at the project's canonical address from `site_status` / `my_projects`. Take addresses from here, never assemble them.

Which git providers Layero supports and which of them the organization has connected (GitHub App installations and provider tokens). Call before `import_repo` when you are not sure the provider is connected. Connecting a provider token is done by the person in the dashboard — never ask them to paste the token into the chat.

The user's sites on Layero. Thirty most recent by default. The full list is rarely needed, while flooding half your context with it is easy: an active user has dozens of projects. `url` is the canonical (production) address. `repo`, `branch` and `root_directory` say where the project is built from: all three are null for a project without a repository (CLI or `publish_site`); `root_directory` is the app folder inside a monorepo, null for the repository root.

Create an empty project with no repository — an address reserved for a later `publish_site` or `npx layero@latest deploy`. For a project FROM a repository use `import_repo` instead. Nothing is built or served yet: the address answers only after the first publish.

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.

DEPRECATED — use `publish_site`. Same behaviour, same arguments. Kept for one release (removed in the next) so that configs and prompts written before 17.09.2026 keep working; new instructions must call `publish_site`.

Publish a static site to Layero — from here, with no terminal. Takes ANY ready static bundle, so it is the answer to "deploy my site" when the project has no connected repository. Requirements — `index.html` at the root, at most 200 files, 8 MB in total, 2 MB per file. Binary files (images, fonts) must come with `encoding="base64"`; sent as text they are silently corrupted. Do NOT use it for a project with a connected repository (`site_status` shows one): the next git push would overwrite what you published. Publishing without a Layero account is not possible from here — the server requires sign-in. For that case there is the CLI: `npx layero@latest deploy --claim` deploys first and lets the person claim the site later. An empty project for a future publish is created with `project_create`. A project that still needs a build step (Vite, Next, Astro — anything where the answer is `npm run build`) does NOT go here: publish its build output, or tell the user to run `npx layero@latest deploy`, which builds on our side. Send the ACTUAL file contents: the server does not remember the bundle between calls. If the user edited the text after generation, pass the current versions, or what gets published is what used to be there. Pass `project` (the id of an existing project) when republishing the same site; without it the platform finds a project with that name or creates a new one. Returns as soon as the build finishes, or after ~40s with `status` `building` and the `deploy_id` — the build keeps going on its own. Never call this tool a second time to "retry" a build that is still running: that starts a SECOND build. Follow `next_action`.

What is really published: headings, copy, forms, meta, links. Call it BEFORE changing anything on a live site and AFTER a publish, to make sure the expected version arrived. Without it you edit blind: what lies on the user's disk and what visitors are served are different things, and they drift apart silently. The result is a STRUCTURE, not raw HTML: a page with inline styles would eat half your context, while what you need from it is headings, copy, forms and meta. The full source is on the user's disk. `served_fallback=true` means this path was answered with the home page: there is no page at this address, and the storage answered the missing key with its `index.html` and a 200. Do not take that for success.

One named markup transformation — with a predictable result. The tool PUBLISHES NOTHING. It returns the changed HTML; showing it to the person, getting consent and calling `publish_site` is your job. Never rewrite someone's site silently. Transformations are idempotent: a repeated call changes nothing and honestly answers `changed=false`. An empty list of changes is not an error, it means "there was nothing to apply". ⚠️ WHAT IS NOT HERE AND WHY. Fonts from third-party hosts, re-encoding images to webp and untangling inline styles are NOT included: they need the files themselves, which the server does not have, or a judgement about the intended look. `site_issues` names those problems — with a location and an explanation; whoever holds the files fixes them. The gain is measured with `check_performance` BEFORE and AFTER the publish. A difference under three points is measurement noise, not an improvement — say so.

Run a build again — a failed one as is, or the latest commit afresh. Default (`redeploy=false`): queue the SAME build again. Allowed only for builds in the `failed` or `cancelled` state. On a running build (`queued`, `building`) the platform refuses — that is not an error but protection against a second parallel build; on a `ready` build it refuses too — use `redeploy=true`. `redeploy=true`: start a NEW build of the branch's latest commit without a push. This is how changed project settings (`project_settings`) or environment variables (`env_vars`) get applied. The result goes live the same way a push to that branch would — on the production branch that is production, so make sure the person wants that. Projects without a repository are rebuilt by deploying the folder again (`npx layero@latest deploy` or `publish_site`). ⚠️ A plain retry makes sense when the cause was external (network, registry, timeout). If the build failed on the code, a retry gives the same result: `diagnose_deploy` first, then the fix, and only then a retry.

Put the previous working build back on the live address. CHANGES WHAT VISITORS SEE — ask the person before calling unless they asked for a rollback explicitly. The action is reversible (you can roll forward again), but the time visitors spent on the wrong version cannot be taken back. ⚠️ For apps (`ssr_next`, `node_web`, `python_web`, `streamlit`, `gradio`, `flask`) a rollback works differently from static sites and is often impossible: an app has no ready artifact to simply switch to. If the platform refuses, explain that to the person plainly and suggest rebuilding the earlier commit — do not repeat the call.

Search docs.layero.ru — no token needed. Use it before guessing how the platform works: build settings and `layero.json`, environments and preview URLs, custom domains, env vars, runtime apps, Data API, CLI flags and JSON events. Returns the page title, a direct URL (with anchor) and a snippet; open the URL with your own fetch tool when the snippet is not enough. `score` is relative within one answer: a rare query word found in a page title weighs most, and a page matching every word ranks above one repeating a single word. The index is the site's own search index, refreshed hourly.

Site traffic: totals, direction and top sources. The time series is collapsed into a direction and breakdowns are cut to five: ninety chart points are useless in your context, and the conclusion is yours to draw anyway.

Concrete problems of a page — each with its location and what to do. This is NOT a score. The score comes from `check_performance`, and a score gives nothing to fix: "73 out of 100" does not say what to change. Here is only what has a location and a clear action: blocked indexing, resources from foreign hosts, raster images without webp, missing meta and alt, forms with no recipient. Findings are sorted by importance. Do not dump the list — name the two or three main ones and ask whether to fix them.

A screenshot of the latest built version of the site — how it looks. Complements `read_site` (what is on the page) and `site_issues` (what is wrong with it) with the third question: how it looks. Useful before and after a visual change. ⚠️ The screenshot is taken at BUILD time, not now. Right after a publish a fresh one does not appear instantly — do not present the previous one as the result of your change. An image costs far more context than text. Do not call it "just in case": for "what is wrong with the site" `site_issues` is cheaper and more specific.

How a site is doing: where it is built from, whether the address is answering, and how the latest build ended. One call instead of three (project, deploys, live check of the address). `source` / `repo` / `branch` / `root_directory` say where the project is built from — a connected repository means deploys go through git. `serving` is true when the SITE ITSELF answered — any response that is not a Layero platform screen and not a 5xx. An API server that has no `/` route answers with its own 404: that is a running app, not a broken site — check a real route with `path`. `answered_by` tells who replied: `site`, `platform` (a Layero screen, named in `platform_screen`: `unavailable`, `coming-soon`, `starting`, `not-found`, `suspended`) or `none` (no response). Redirects are not followed: `redirect_to` shows the target. Waiting for a build: while the latest build is running the answer carries `poll_after_s` — call again after that many seconds. Or pass `wait_s` and the server waits for the build itself (mind your client's tool-call timeout, see the argument). `waited_s` says how long the call waited. Static sites: `served_fallback: true` means the requested `path` was answered with the HOME page (a missing file is replaced by `index.html` with code 200) — the address answers, but this page does not exist.

Who is connected to Layero and how many projects they have. Call this first when you are unsure the token is configured: a clear error here is cheaper than one halfway through a deploy.