# Layero MCP server

Source: https://glimind.com/server/mcp-registry%2Fru.layero%2Flayero
Registry id: `mcp-registry/ru.layero/layero`
Status: live (checked 2026-10-27T09:01:53.237Z)

## Verdict

Layero MCP server answered 99.73% of Glimind's liveness checks over 30 days, better than 22% of MCP servers, with 2125 ms median handshake and 36 outages in 90 days. Its agent-readiness grade is A (91/100) across 36 tools, costing an agent about 13,634 tokens to load. Checked every few minutes; no tool is ever called.

## Measurements (30 days)

| Metric | Value | Better than |
|---|---|---|
| Uptime, 30 days | 99.73% | 22% of MCP servers |
| Median handshake latency | 2125 ms | 4% of MCP servers |
| p95 handshake latency | 5119 ms | — |
| Checks in 30 days | 4,844 | — |
| Outages, 90 days | 36 | — |
| Median recovery | 3 min | — |
| Agent-readiness score | 91/100 (A) | 70% of MCP servers |
| Tools | 36 | — |
| Tool-list size for an agent | ~13,634 tokens | 14% of MCP servers |
| Days observed | 29 | — |

## Install

```json
{
  "mcpServers": {
    "layero-mcp-server": {
      "type": "http",
      "url": "https://mcp.layero.ru/mcp"
    }
  }
}
```

Claude Code:

```sh
claude mcp add --transport http layero-mcp-server https://mcp.layero.ru/mcp
```

## Tools (36)

- `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 fi
- `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 pro
- `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
- `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 anothe
- `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 return
- `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 th
- `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 platf
- `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 
- `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 (sign
- `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 
- `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
- `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 
- `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 
- `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
- `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 l
- `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 p
- `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 "w
- `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
- `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` w
- `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 
- `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 `
- `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
- `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.202
- `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 co
- `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 ver
- `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 
- `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 `fai
- `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. 
- `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 
- `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 i
- `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
- `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) wit
- `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
- `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 

Measured by Glimind (https://glimind.com): MCP handshake + tool list only, no tool is ever called. CC BY 4.0.