Layero

Собрать лендинг по идее

compose_landing

Drive the 3-step quiz flow and produce a complete landing.

This is the **main entry point**. Don't ask the user questions in chat
before calling this — the tool opens native quiz dialogs in the IDE
itself. Call this immediately when the user describes what they want.

The three quizzes are:

1. **Motivation** — what's being built, for whom, the desired action.
2. **Look & feel** — palette, tone, optional references.
3. **Final picks** — design system (top 3 matched), where submissions go,
   project name slug.

Returns a ``ComposeResult`` with the file bundle to write to disk. The
agent then writes the files using the IDE's filesystem tool and proceeds
to integration setup / deploy.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`user_message`	Yes	The user's full message verbatim — do not paraphrase. Used to pre-fill quiz defaults and inform matching.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No
`brief`	No
`files`	No
`status`	Yes
`structure`	No
`integration`	No
`next_action`	No
`design_rules`	No
`project_name`	No
`design_system`	No
`category_guide`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedAug 3, 2026

changedOutput schema / properties / status / enum

Previous value: -[
-  "ok",
-  "needs_chat_input",
-  "cancelled"
-]New value: +[
+  "ok",
+  "needs_app_input",
+  "needs_chat_input",
+  "cancelled"
+]

Changed1 schema field changedAug 2, 2026

addedOutput schema / $defs / FilePayload / properties / encoding

Added value: +{
+  "default": "text",
+  "description": "Use `base64` for binary files — images, fonts, favicons. Text files (html/css/js/svg) stay `text`. A binary sent as text is silently corrupted.",
+  "enum": [
+    "text",
+    "base64"
+  ],
+  "title": "Encoding",
+  "type": "string"
+}

First observedJul 26, 2026

TDQS

A4.6/5.0

Behavior4/5

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

The openWorldHint=true annotation declares the tool opens external dialogs, and the description reinforces this by explaining the native quiz dialogs in the IDE. It adds value beyond the annotation by describing what the dialogs collect (skills, palette, design system, submissions, slug) and what the return value (ComposeResult) contains. It's not a pure read/write tool, so the annotation covers the 'opens world' aspect and the description adds the flow context.

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

Conciseness4/5

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

The description is well-structured with a bolded main intent, clear instruction, and a numbered breakdown of the three quiz steps. The final paragraph explains the output and follow-up. A bit longer than strictly necessary but every sentence contributes value; the structure makes it scannable. Slight verbosity in listing all quiz contents, but it's useful for the agent.

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?

Given the output schema exists (ComposeResult), the description appropriately references it without re-explaining return fields. The tool has only one param, an openWorld hint annotation, and the description covers the flow, prerequisites (call immediately, don't ask questions), and post-conditions (write files, proceed to integration). This is complete for an orchestration/entry-point tool.

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?

The single parameter user_message is the only one, with 100% schema coverage in the schema description itself ('verbatim — do not paraphrase'). The tool description adds crucial context: the message is 'used to pre-fill quiz defaults and inform matching,' which explains why verbatim preservation matters. For a single-param tool, this is strong semantic guidance.

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 clearly states the tool drives a 3-step quiz flow and produces a complete landing. It explicitly declares itself as 'the main entry point' and details the three quiz steps (Motivation, Look & feel, Final picks). This distinguishes it clearly from siblings like publish_landing, read_site, or refactor_site which are post-composition operations.

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

Usage Guidelines5/5

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

Excellent guidance: explicitly says DON'T ask questions in chat before calling, states the tool opens native quiz dialogs in the IDE, says to 'call this immediately when the user describes what they want.' It also explains the follow-up workflow (write files via IDE filesystem tool, then proceed to integration/deploy), which maps well against sibling tools like add_integration and publish_landing.

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.8/5.0

Disambiguation5/5

Each tool targets a distinct resource and action. The deploy lifecycle is cleanly separated into cancel, retry, rollback, diagnose, logs, list, and status, while the site_* tools each answer a different question. Even the two compose_landing tools are explicitly differentiated for model vs. internal use.

Naming Consistency3/5

Tool names mix verb-first patterns (check_domain, list_deploys, connect_analytics) with noun-first patterns (site_issues, deploy_logs, env_vars), and some are bare verbs (rollback, whoami). The naming is descriptive and readable, but not consistent enough to predict the style for a new tool.

Tool Count2/5

27 tools exceeds the typical well-scoped range and pushes into 'too many' territory. While the server covers a broad platform scope, many tools are highly specialized (check_copy, site_screenshot), and an agent may be overwhelmed by the sheer number of choices. Consolidation could reduce the load.

Completeness4/5

The core lifecycle is solid: compose, publish, monitor, diagnose, and rollback, with supporting tools for domains, analytics, performance, and content inspection. However, there are no delete/remove operations for projects, domains, or integrations, and integration management is limited to adding. These are minor gaps that agents can work around, but they are notable for a full platform.

Собрать лендинг по идее

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources