Layero

Переменные окружения проекта

env_vars

Destructive

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`keys`	No	Для `action="unset"`: имена переменных, которые убрать.
`action`	No	`list` — показать имена (значения не возвращаются никогда), `set` — задать переменные из `values`, `unset` — удалить переменные, перечисленные в `keys`.	list
`values`	No	Для `action="set"`: пары имя → значение. Остальные переменные проекта сохранятся — присылать их заново не нужно.
`project`	Yes	Проект: слаг (`my-site`) или id. Слаг — то, что видно в адресе сайта; если пользователь назвал сайт словами, возьми слаг из `my_projects`.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`changed`	No
`project`	Yes
`variables`	Yes
`next_action`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses the critical security invariant (values never read back), the prohibition on echoing secrets, and the new-deploy requirement. This is exactly the behavioral context an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a clear lead sentence followed by essential security and usage notes. While lengthier than minimal, every sentence contributes operational value, and the formatting makes it scannable.

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?

With a full schema, a true output schema, and a rich description covering security, deployment, and action semantics, the agent has everything needed to select and invoke the tool correctly.

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 already documents all four parameters with 100% coverage. The description adds meaningful nuance: set preserves other variables, unset only affects named keys, and list only returns names/lengths. This goes beyond the schema's field-level descriptions.

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?

The description opens with a clear verb+resource: 'Project environment variables: list names, set them, remove them.' This unambiguously differentiates it from siblings (domains, analytics, design systems) and enumerates the three concrete actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit operational guidance: when to use set vs unset, that list never returns values, and that a deploy is needed after changes. It doesn't explicitly exclude alternatives, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Layero tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation3/5

Most tools are distinct, but there's real confusion risk between the deploy-related set (cancel_deploy, retry_deploy, deploy_logs, diagnose_deploy) and the site-inspection set (site_status, read_site, site_issues, site_screenshot) where purposes overlap. compose_landing vs compose_landing_submit are differentiated mostly by an obscure note rather than naming. Several tools address similar concepts (landing composition, publishing, deploy) making agent misselection plausible.

Naming Consistency3/5

Most tools use a clean verb_noun pattern (list_deploys, connect_domain, check_domain, publish_landing, read_site, rollback). However, conventions are mixed: some use compose/x/check/y (check_copy, check_domain, check_performance) while others use site_x (site_status, site_analytics, site_issues, site_screenshot) with inconsistent ordering. Descriptions mix English and Russian heavily, though that's content not naming.

Tool Count4/5

27 tools is a large but arguably justified surface for a full site-building/deploying/monitoring platform spanning composition, domain management, deploys, performance, analytics, and environment configuration. It sits slightly above what feels tight, but each tool has a defined role in the overall workflow.

Completeness4/5

The surface covers the full landing lifecycle: compose, publish, deploy, monitor, rollback, diagnose, and connect external resources (domain, analytics, integrations). Minor gaps: no explicit tool for site deletion/teardown, only read_site for editing with refactor_site being narrow, and no way to update an existing landing's text beyond refactor. Still, core CRUD and operational flows are covered.

Resources

Need Help?