MCP tools
The Layero MCP server: https://mcp.layero.ru/mcp, Streamable HTTP
transport, named layero in client configs. How to connect is described on
Connect an agent; this page is what the server can do, one
line per tool.
Account
| Tool | What it does |
|---|---|
whoami | Who is connected: user, organisation, token expiry. |
my_projects | The list of projects with addresses and source (repository or CLI); the repo argument keeps the projects of one repository. |
list_sources | Git providers (GitHub, GitVerse, GitLab, GitFlic, SourceCraft) and the organisation's connections. |
import_repo ⚠️ | Create a project from a repository: GitHub through the App installation, the others through the organisation's connection. Once linked, it finishes the setup wizard and starts the first build itself. It does not write the framework, build command or output folder into the project (since 2.3.1): the builder detects them from the repository on every build; the result carries setup (applied / pending / failed), first_deploy_id and an honest next_action. deploy=false leaves the project in the setup wizard. Provider not connected — the answer is needs_connection with the dashboard address; the provider token is connected by the person, not the agent. An app in a monorepo subfolder takes the root_directory argument (apps/web): one project builds one folder. A repository that is already linked answers already_linked with the list of projects (address, folder, branch); a second project from the same repository is only created with a different folder. |
project_create ⚠️ | An empty project with no repository — an address reserved for a later publish_site or npx layero@latest deploy. |
project_settings ⚠️ | Read or change a project's build settings: app folder, install and build commands, output folder, project type. Shows where every effective value comes from and the layero.json warnings. The way out when detection was wrong: change the setting, then retry_deploy with redeploy=true. |
Site and deploys
| Tool | What it does |
|---|---|
site_status | Site state: latest deploy, address, repository, branch and app folder. answered_by tells the site's own answer from a platform screen: an API server with no / route answers its own 404 and counts as up; the path argument checks a specific route, and served_fallback warns that a static site answered it with the home page. wait_s (up to 120 s) waits for a running build; without it poll_after_s suggests the polling interval. When there has been no build yet it says so instead of passing a missing build off as a successful one. |
list_environments | The project's environments — one per branch — with addresses and the state of the latest build. |
list_deploys | The project's build history: status, source (git or upload), time in the queue and build duration. |
deploy_logs | Build and application logs. npm http lines are hidden by default and counted in noise_hidden; include_noise=true shows everything. |
diagnose_deploy | Why a build failed — with a log breakdown and the next step. build_facts says what the build used: framework, install and build commands, output folder, Node version, and where each value came from. |
retry_deploy ⚠️ | Restart a build: a failed one as it is; redeploy=true rebuilds the latest commit of a repository project without a push. |
cancel_deploy ⚠️ | Cancel a running build. |
rollback ⚠️ | Roll production back to a previous build. |
publish_site ⚠️ | Publish ready static output (a folder with index.html) without the CLI; creates the project if it does not exist. publish_landing is a deprecated alias of publish_site. |
env_vars ⚠️ | Read, set or delete the project's environment variables. |
Domains
| Tool | What it does |
|---|---|
list_domains | The project's domains and their state. |
connect_domain ⚠️ | Connect your own domain: returns the DNS records to create. |
check_domain | Check whether the domain works: DNS and certificate. |
Site content
| Tool | What it does |
|---|---|
read_site | Read a page of the published site as text and markup. |
site_screenshot | A screenshot of a site page. |
site_issues | What to fix on the site: broken links, meta tags, accessibility. |
refactor_site | Propose a markup change — returns a patch, touches no files. |
check_copy | Proofread Russian text against Layero's editorial rules. |
check_performance | Measure site speed: Core Web Vitals, Lighthouse. |
Analytics
| Tool | What it does |
|---|---|
connect_analytics ⚠️ | Connect Yandex Metrica to the project. |
site_analytics | Site traffic over a period. |
Data API
| Tool | What it does |
|---|---|
data_api_status | Whether the Data API is enabled for the project's database, and its address. |
data_api_methods | Methods (tables and functions) and who may call them. |
data_api_grant ⚠️ | Open or close access to a method for a role. |
data_api_keys ⚠️ | Issue or revoke Data API keys. |
data_api_origins ⚠️ | Sites allowed to call from the browser (CORS). |
data_api_probe | A trial call of a method — check that access and the response are as expected. |
Documentation
| Tool | What it does |
|---|---|
search_docs | Search docs.layero.ru; touches no account data. |
Which tools need a person's consent
Tools marked ⚠️ change the site, the project or access — the server
declares them without readOnlyHint, and the client (Claude Code, Cursor,
Codex) asks for confirmation before the call. The rest only read, and the
client calls them without asking.
The rule for an agent: before rollback, publish_site, a writing
env_vars, data_api_grant and data_api_keys, tell the person exactly what
will change and wait for the answer — even when the client does not require
confirmation.
Sign-in
What works without sign-in. The documentation is always available:
search_docs, check_copy and refactor_site do not touch the account and
answer without a token — connect the server and ask about the platform right
away.
Every other tool works with the account: the first such call without a token
gets 401 with WWW-Authenticate, and a client that supports OAuth (Claude
Code, Cursor, Codex, VS Code) opens the browser itself — all that is left is
to click "Allow access". The authorization server is api.layero.ru, the resource
metadata is https://mcp.layero.ru/.well-known/oauth-protected-resource. For
CI and environments without a browser — the header
Authorization: Bearer $LAYERO_TOKEN; how to issue a token is on
Connect an agent. Deploying without an
account exists only in the CLI: npx layero@latest deploy --claim.
URL parameters: project and read_only
The server's scope can be narrowed right in the connection address:
https://mcp.layero.ru/mcp?project=<slug>
https://mcp.layero.ru/mcp?project=<slug>&read_only=true
project=<slug>— every tool works with this project only;my_projectsreturns just it, and a call with another project is refused.read_only=true— the ⚠️ tools are not declared at all. Handy for an agent that should only diagnose.
The parameters go into the client config, in the url field — no separate
mechanism is needed.