bots.st/layero
Layero
Deploy and manage hosted sites, domains, Data API
3473 ms
answered our call
- State
- Answered
- Protocol
- MCP 2025-06-18
- Tools listed
- 38
- Answered
- 3 of the last 3 calls
How to reach it
- MCP, HTTP
https://mcp.layero.ru/mcp
What it can do
| Tool | What it says it does |
|---|---|
cancel_deploy | Stop a build that is still running. The live address does not change — the previous version stays on it. |
check_copy | 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… |
check_domain | 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. |
check_performance | 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… |
check_rules | Check the published site against Layero's anti-phishing rules (https://layero.ru/rules): collecting passwords, card details or wallet recovery phrases of another service, fake security warnings, vote and prize lures that send visitors to another domain. Checks what a visitor sees… |
connect_analytics | 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… |
connect_domain | 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… |
data_api_auth | Sign-in of the app's users: what is enabled, and the sender name of its emails. Provider keys are never returned. Connecting Yandex, VK ID or Sber ID needs a secret — that is done by the person in the dashboard or with `layero data auth provider set` in a terminal, not through the… |
data_api_buckets | Storage buckets of a database: list and create — without a secret key. Files must be enabled for the database. A private bucket opens nothing by itself: reading and uploading are decided by storage policies (the dashboard → Files → Policies, or SQL on storage.objects). Creating needs… |
data_api_grant | 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… |
data_api_keys | 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… |
data_api_methods | 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… |
data_api_origins | 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… |
data_api_probe | 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… |
data_api_status | Whether the database has the Data API enabled, its address, keys and the sites allowed to call it. Keys are shown by prefix; the public key also comes with its value (it is not a secret: it ships in the site bundle). Secret keys are never returned or stored. Enabling the API goes… |
deploy_logs | 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… |
diagnose_deploy | 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… |
env_vars | 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… |
import_repo | 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… |
list_deploys | 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… |
list_domains | The project's own domains and their state. |
list_environments | 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… |
list_sources | 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 —… |
my_projects | 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_create | 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. |
project_settings | 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… |
publish_landing | 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_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… |
read_site | 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… |
refactor_site | 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… |
retry_deploy | 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… |
rollback | 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… |
search_docs | 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)… |
site_analytics | 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. |
site_issues | 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… |
site_screenshot | 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… |
site_status | 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… |
whoami | 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. |
In its maker's words
Deploy and operate sites on Layero — hosting with build servers in Russia: domains, env, Data API.
- Website
- docs.layero.ru/agents
- Source
- github.com/LayeroInfra/layero-agents
- Publisher
- layero.ru
- Listed from
- the official MCP Registry as
ru.layero/layero - Version
- 2.4.0, updated 19 Sep 2026
- Kinds of work
- Cloud and DevOps, Domains and websites, Data and databases
The domain it lives on
- layero.ru
- registered 18 Apr 2026 (7 months ago), at REGRU-RU, its home page is a working site
From our own crawl of domain names: registry records and the home page as our crawler last saw it.
Every call we made
| When | What happened | Time |
|---|---|---|
| Answered | 3473 ms | |
| Answered | 3217 ms | |
| Answered | 2173 ms |
Next door
Is this your bot? Claim its address to add a verified badge and keep the listing current.