Layero

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

The annotations provide readOnlyHint and idempotentHint, and the description adds valuable context beyond this by explaining that the tool 'Returns the integration recipe' and that 'The agent executes the steps itself — runs terminal commands, edits files, deploys a relay if needed.' This clarifies the tool's non-mutating nature and sets expectations about the agent's follow-up actions. It aligns well with the annotations and adds meaningful behavioral detail.

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

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

The description is highly concise: two sentences that front-load the primary purpose and immediately follow with the essential behavioral note about the recipe and agent execution. Every sentence earns its place, and there is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 param, 3 enum values), an output schema exists, and the annotations cover safety, the description covers the key contextual points: what the tool does and how the agent must act on the result. A minor gap is the lack of mention of prerequisites (e.g., the form must exist), but this is not critical for invoking the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage for the only parameter 'kind', including a detailed description of each enum value. The tool description does not add any additional parameter semantics, so it relies entirely on the schema. This matches the baseline score of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Wire form submissions into a destination.' It identifies a specific verb and resource, making it easy to understand the tool's function. However, it does not explicitly differentiate this from sibling tools like connect_analytics or connect_domain, so it lacks the extra distinction that would earn a 5.

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

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

The description implies the tool is used for setting up form-to-destination integrations (telegram, google_sheets, custom), but it provides no explicit guidance on when to use it over alternatives or any exclusions. The purpose is clear enough to infer usage, but there is no direct 'when-to-use' or 'when-not-to-use' statement.

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

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

The annotations provide openWorldHint=true but no read-only/destructive hints, so the description carries the burden. It discloses a key behavioral fact: the live address is unchanged, leaving the previous version. However, it does not state whether cancellation is destructive to the deploy record, whether it can be resumed, or whether there are side effects beyond stopping the build.

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

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

Two short sentences, both earning their place. The first states the primary action clearly, and the second adds a crucial non-destructive guarantee. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a cancellation tool with an output schema, a full return-format explanation is unnecessary. The description omits failure cases (what happens if no build is running, or if the build already finished) and does not clarify whether the cancel applies to the most recent deploy vs. the live one — though the deploy parameter default partially addresses this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage — project and deploy are both documented in the schema itself. The deploy parameter (optional, defaults to newest build) is meaningfully explained in the schema as "id сборки. Без него берётся самая свежая." The description adds little beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool stops an in-progress build ("Остановить сборку, которая ещё идёт"). It identifies the verb (cancel/stop), the resource (build/deploy), and the scope (only in-progress ones). It distinguishes from siblings like deploy_logs, retry_deploy, and rollback by focusing on cancellation of an ongoing build.

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

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

The description establishes the key usage context: it only applies to builds "которые ещё идёт" (still running). It clarifies that the live URL is not affected — the previous version remains. This is a clear behavioral boundary, though it does not explicitly name sibling alternatives like rollback or retry_deploy for comparison.

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

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

Annotations already indicate readOnly and idempotent behavior. The description adds determinism ('Это КОД, а не суждение модели... один и тот же текст даёт один и тот же список находок'), the types of errors caught, and the presence of ready-made replacements. It also states what it does not cover, providing a clear boundary.

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

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

The description is well-structured with short paragraphs, a clear first sentence, and a dedicated exclusions section. Every sentence adds meaningful information—error examples, determinism, instruction, and alternative resource—without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and full parameter schema coverage, the description adequately covers behavioral expectations, scope, and exclusions. It leaves no significant gaps in context, making the tool easy to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with detailed descriptions, including the mutually exclusive relationship between 'text' and 'project'. The tool description does not add parameter-specific meaning beyond the schema, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Механические ошибки русской типографики — с точным местом и заменой' and lists specific error types, clearly defining the tool's scope. It also distinguishes itself from the editorial style resource 'layero://editorial/ru', making the purpose unambiguous.

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

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

The description explicitly says 'ЧЕГО ЗДЕСЬ НЕТ... Прочитай его, если просят «сделать текст лучше»', providing a when-not-to-use condition and an alternative resource. It also gives instructional guidance ('подставляй её, а не переписывай фрагмент по-своему'), clarifying how to act on results.

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

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

Annotations already declare readOnlyHint=true, so the tool is known to be read-only. The description adds valuable behavior beyond that: it triggers an immediate DNS check instead of a background re-check, and it sets expectations that propagation delay is normal. It also implies the domain must be already connected. This is meaningful added context without contradiction.

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

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

The description is very concise: a single opening sentence stating purpose, followed by two short sentences covering behavior and handling of results. It is front-loaded with the core purpose and contains no redundant or irrelevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity, full schema coverage, readOnly annotation, and presence of an output schema, the description is complete. It covers what the tool does, the immediate-execution behavior, what to expect, and how to respond. No critical missing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both `domain` and `project` well-described in the input schema. The description itself does not add extra parameter semantics, but per the rubric, the baseline is 3 when schema covers all parameters, and the description doesn't need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb+resource: 'Check whether a connected domain has started working.' It also specifies the action is a DNS check run immediately, which distinguishes it from sibling tools like `site_status` or `check_performance`.

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

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

The description provides usage context: it runs the DNS check immediately rather than waiting for the background re-check, implying when an immediate answer is needed. It also advises how to handle non-propagated records ('say so and suggest coming back later'). However, it doesn't explicitly name alternative tools or state when not to use it.

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

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

Beyond the readOnlyHint annotation, the description discloses valuable behavior: the verdict comes from the score, not timings; repeated runs vary by at most one point; a run takes tens of seconds; and parallel measurements occupy the queue. This adds significant context without contradicting the annotation.

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

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

The description is compact and front-loaded with the core purpose. Every sentence adds necessary information: the verdict source, the noise threshold, the run duration, and the queue warning. No redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, combined with the rich schema and output schema, gives the agent everything needed to select and invoke the tool correctly. It explains interpretation, parameter behavior, and cautions, leaving no critical gaps for a decision-making agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers both parameters fully (100% coverage). The description goes further by explaining the wait parameter's behavior ('With wait=true the tool waits for you' and warning against parallel use), adding meaning beyond the schema's basic description. Not quite a 5 because project parameter semantics are not enriched.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's primary function: 'Measure a site's speed and say whether it got worse after a deploy.' This specifies a distinct verb, resource, and context, setting it apart from sibling tools like site_status or site_analytics.

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

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

The description provides clear contextual guidance, such as using the score rather than raw timings and treating differences under 3 points as noise. It also advises against parallel measurements. However, it does not explicitly name alternatives or state when not to use the tool, so it falls short of a 5.

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

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

The description discloses that the tool opens native quiz dialogs in the IDE (not chat), which is a critical behavioral trait not captured by the openWorldHint annotation. It explains the full user-visible flow (three quiz categories) and what the tool returns (ComposeResult file bundle) and what should happen next. The description carries the behavioral burden well beyond the single annotation.

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

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

Well-structured with bold section headers and a bullet list of the three quiz steps, making it scannable. Every sentence earns its place: the entry-point callout, the not-in-chat directive, the three quiz categories, and the return value with next steps. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a moderately complex tool (3-step quiz, 1 param, output schema present), the description is complete: it explains what the tool does, when to call it, what the user experiences, what it returns, and the follow-up workflow. The presence of an output schema covers return-value details, and the description fills the behavioral narrative completely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the single parameter user_message is already documented ('The user's full message verbatim — do not paraphrase'). The description adds meaning by explaining how the message is used ('pre-fill quiz defaults and inform matching'), though it doesn't specify what happens with low-information messages. The description adds context beyond the schema's 'do not paraphrase' instruction.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Highly specific: "Drive the 3-step quiz flow and produce a complete landing" names the exact verb (drive quiz flow, produce landing), the resource (landing), and the mechanism (3-step quiz). It explicitly distinguishes itself as the 'main entry point' versus the sibling compose_landing_submit, which handles submission. Clear and unambiguous.

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

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

Provides explicit when-to-use instructions: 'Call this immediately when the user describes what they want' and 'Don't ask the user questions in chat before calling this' — a critical behavioral directive. It also distinguishes the flow from the submit tool and describes the follow-up (write files with IDE filesystem tool, then integration). Clear guidance on when and how to invoke.

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

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

The description explains the invocation mechanism (form calls it via host bridge) which is useful behavioral context. However, the annotations only provide openWorldHint:true, so there's no read/write concern to clarify. The description doesn't disclose what happens on failure, return format, or side effects. For an output-promising tool with an output schema present, this is moderate but not overloaded.

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

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

The description is compact — roughly four short paragraphs serving distinct purposes: purpose statement, usage exclusion, and parity guarantee. Each sentence earns its place. Slightly more verbose than strictly needed, but every clause adds meaningful guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters, an output schema, and 100% schema coverage, the description handles the key gap: how this tool relates to compose_landing. It clarifies the bridge-invocation mechanism and parity behavior. The main omission is any guidance on what happens if inputs are incomplete or invalid, but with good schema coverage, this is a solid baseline.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — every parameter has a description in the schema. The description itself doesn't add parameter-level context beyond noting they come from a form and the result should match post-quiz behavior. Since schema coverage is high, baseline 3 is appropriate; the description doesn't elevate beyond this.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool assembles a landing page from form answers. It differentiates from the sibling compose_landing by explicitly noting this tool is NOT for the model — it's called by the form via a host bridge, while the model should call compose_landing instead. This is a specific verb+resource with strong sibling differentiation.

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

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

The description explicitly states when NOT to use this tool (it's not for the model) and names the alternative (compose_landing). It also clarifies that the assembly uses the same function as post-quiz, so results shouldn't depend on which client the person uses. This is excellent usage guidance with explicit exclusions and named alternatives.

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

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

The description discloses critical behavioral traits: authorization is browser-based, the tool returns a link, and polling is discouraged. The annotation openWorldHint only hints at external interaction, but the description goes beyond by explaining the exact workflow and state-check method, which is not present in annotations.

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

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

The description is concise and well-structured: it opens with the purpose, then highlights the critical browser authorization step, gives clear instructions, and closes with future-checking guidance. Every sentence adds value, with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of OAuth flows, the description completely covers what the agent needs to know: it explains the authorization process, return type (link), and how to poll later. The output schema exists, so return details do not need to be repeated. The tool is fully contextualized among siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides parameter descriptions with 100% coverage, so the baseline is 3. The description adds operational meaning by suggesting calling without the branch argument to check status later, which is useful beyond the schema's static definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool connects Yandex Metrika to a site, which is a specific verb+resource. It distinguishes itself from sibling tools like site_analytics (which likely reads analytics data) by describing the setup/authorization flow.

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

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

The description explicitly states when to use the tool (to connect Metrika), warns that authorization happens in a browser, instructs the agent to show the link to the user, and advises against polling. It also mentions checking later via the same tool without the branch argument or via site_analytics, providing clear alternatives.

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

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

The description discloses key behaviors beyond annotations: a human must configure DNS, the platform rechecks automatically, and waiting is counterproductive. This adds rich context beyond the `openWorldHint` annotation and aligns with the external interaction hint.

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

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

The description is front-loaded with a one-sentence purpose, followed by a critical warning and a brief normalization note. Every sentence earns its place, and the structure is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return value details are not needed. The description fully covers the human-in-the-loop workflow, DNS timing, and follow-up action via `check_domain`, making it complete for the task's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining URL normalization ('reduces https://shop.example.com/page to shop.example.com itself'), which is not in the schema and clarifies acceptable input formats beyond the schema's restrictions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Connect a custom domain to a site,' a specific verb+resource statement. It clearly distinguishes from sibling tools like `check_domain` (verification) and `list_domains` (listing) by focusing on the connection action.

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

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

Provides explicit usage guidance: show DNS records to the user, do not wait for readiness, and check later via `check_domain`. It names the alternative tool and explains the timing and workflow, which is ideal for agent guidance.

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

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

Annotations only declare readOnlyHint=true. The description adds that the response is a tail, that a `truncated` field indicates how many lines were trimmed, and warns not to present the tail as the entire log. This goes beyond the annotations and is valuable behavioral context.

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

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

The description is concise and well-structured: three short paragraphs covering purpose, usage guidance, and a critical warning. Each sentence earns its place, with front-loaded core purpose and no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only log retrieval tool with 4 parameters, an output schema, and sibling tool context, the description is complete. It gives usage context relative to `diagnose_deploy`, explains return shape and pitfall, and relies on schema for parameter details. There is no significant missing context for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover 100% of the parameters with detailed explanations, so baseline is 3. The description itself does not elaborate on individual parameters but its mention of the `truncated` field indirectly relates to output rather than parameters. It adds little beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns raw log strings, contrasting with `diagnose_deploy` which provides parsed diagnostics. It specifies that the output is a tail of the log, thus a specific verb+resource with scope.

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

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

Explicitly instructs to start with `diagnose_deploy` and only use this tool when raw logs are needed, such as when the cause is unclear or investigating application behavior rather than failures. Names the alternative tool directly and gives clear when/when-not guidance.

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

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

Beyond the readOnlyHint annotation, the description discloses that the response is not a log tail but a pre-parsed 'neighbourhood of the fatal line', and that it contains verdict and summary fields. It also reveals the default behavior of using the latest build. This adds meaningful behavioral context.

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

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

The description is about five short sentences, each earning its place. It front-loads the core purpose, then covers parameter behavior, response nature, and workflow—no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description doesn't need to detail return fields. It covers the tool's purpose, default behavior, response semantics (verdict/summary), and the self-service workflow. It is sufficiently complete for an agent to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds extra value by explaining the semantic implication of the deploy parameter: omitting it uses the latest build, which 'reflects the current state'. This clarifies the mental model beyond the schema's 'default: null'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Why a deploy failed — with the cause parsed out, not a raw log.' It clearly differentiates from raw-log tools like deploy_logs by emphasizing the parsed cause and the 'neighbourhood of the fatal line', making it distinct among siblings.

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

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

It gives explicit context about the deploy parameter: without it the latest build is used, and to analyze an older one you pass its id. It also implicitly excludes raw log use by stating 'not a raw log', though it does not name a specific alternative tool.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the behavioral context that the tool reveals build outcomes and current-live state, which is beyond what annotations alone convey. It doesn't describe pagination or response format, but with output schema present, this is acceptable.

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

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

Three sentences, zero waste. Opens with the core function, then usage context and an alternative. Every sentence earns its place with distinct information—purpose, downstream consumers, and exclusion.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with 2 params (1 required), full schema coverage, annotations, and an output schema present, the description is complete. It covers purpose, usage when to reach for it, and ties to related tools. Nothing essential is missing for agent selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% per context signals, so both parameters are documented in the schema. The description adds practical value on the 'project' parameter through a sibling reference (my_projects for slug lookup) that isn't in the schema, enriching agent guidance. Baseline 3 plus this added semantic context justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what it does: lists recent project builds, their outcomes, and which one is currently live. It distinguishes itself well from siblings like site_status and explicitly names rollback and diagnose_deploy as downstream purposes. The verb+resource+scope is specific and clear.

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

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

The description gives explicit when-to-use guidance: pick a target for rollback or diagnose_deploy. It also explicitly excludes a case—'what's wrong with the site right now'—and points to site_status as the cheaper alternative. This is exemplary usage guidance with named alternatives and exclusions.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds the qualifier 'ships with', clarifying that the catalogue is the built-in systems, not user-created ones. This is useful context beyond the annotations.

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

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

The description is a single, direct sentence with no wasted words. It efficiently states the action, object, and scope, making it optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless, read-only tool with an output schema and annotations, the description fully communicates its function. The 'ships with' phrase adds necessary context about the source of the list, leaving no significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema is fully covered. The description adds no parameter details, but none are needed. The baseline of 4 applies for parameterless tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Return the catalogue of design systems Layero ships with' specifies the verb (Return), resource (catalogue of design systems), and scope (pre-installed systems). It clearly distinguishes from siblings like add_integration or check_domain, which handle different concerns.

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

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

The description implies the tool is for retrieving the pre-installed design system catalogue, but it offers no explicit guidance on when to use it vs alternatives or any exclusions. Since no sibling tool competes directly, usage is left to inference.

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

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

Beyond the annotations (readOnlyHint, idempotentHint), the description adds minimal behavioral context. 'Their state' hints at return content, but there is no mention of pagination, permissions, or whether it only lists connected domains.

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

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

The description is a single short phrase with no waste, but it is under-specified rather than efficiently concise. It lacks a verb and sufficient context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations cover safety, the description is minimally adequate but lacks usage context and behavioral details. It could benefit from stating what 'state' includes and when to use this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully documents the 'project' parameter, including the slug/id distinction and how to derive the slug. The description itself adds no parameter semantics, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource ('domains') and scope ('project's own'), but lacks an explicit verb like 'lists' or 'returns'. It is clear enough given the tool name, but does not differentiate from sibling tools like check_domain or connect_domain.

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

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

No guidance is provided about when to use this tool versus alternatives. The description does not mention that check_domain is for individual domain checks or connect_domain for adding domains.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds only the context that these structures are the ones 'Layero ships with,' which helps clarify scope but does not reveal additional behavioral details like pagination or response format.

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

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

The description is a single, focused sentence: 'Return the catalogue of landing structures Layero ships with.' It is perfectly sized, front-loaded with the action verb, and contains no superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a parameterless, read-only list tool with an output schema available. The description clearly explains what the tool returns and the source of the data. Complexity is low, so the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is trivially 100%. According to the rubric, a 0-parameter tool gets a baseline of 4. The description adds no parameter-specific details, but none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb 'Return' and specifies the resource as 'the catalogue of landing structures Layero ships with.' This distinguishes it from sibling tools like list_domains and list_design_systems by explicitly naming 'landing structures' as the subject.

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

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

The description offers implicit usage guidance: it is a list tool for retrieving a catalog. However, it does not explicitly state when to use this tool over alternatives like list_design_systems or list_domains, nor does it provide any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context by disclosing that only the 30 most recent sites are returned by default and that fetching the full list can flood context. This goes beyond the annotation metadata.

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

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

The description is two short sentences, front-loaded with the core purpose. The first sentence states the resource, and the second explains the default behavior and why the full list is rarely needed. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple one-parameter tool with an output schema present. The description covers the essential behavior (default limit, context cost) and is fully sufficient for an agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema description for the 'limit' parameter already provides the same default value (30) and rationale (only raise if looking for an old site). The description adds no additional parameter semantics beyond what the schema already conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'The user's sites on Layero,' which clearly identifies the resource being accessed. However, it lacks an explicit verb like 'list' or 'retrieve,' though the context of 'Thirty most recent by default' implies a listing operation. It distinguishes from siblings like list_domains and list_structures.

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

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

The description gives context on the default limit (30) and advises against requesting the full list, which is useful operational guidance. However, it does not explicitly compare with alternative tools or state when-not-to-use this tool, leaving usage boundaries inferred rather than explicit.

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

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

Beyond the weak `openWorldHint` annotation, the description discloses several critical behaviors: silent corruption of binaries sent as text, server statelessness requiring actual file contents, async return with `status` `building` and `deploy_id`, and a strong warning against calling again to retry a running build. This is exactly the kind of 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.

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

The description is dense but each sentence serves a purpose: scope, constraints, exclusion, statelessness, project param, and async behavior. It is front-loaded with the primary use case and then systematically addresses pitfalls. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex deployment tool with async behavior and file constraints, this description is fully complete. It covers constraints, prerequisites, stateful behavior, retry guidance, and return semantics, so an agent can invoke it correctly without external knowledge. The presence of an output schema further reduces ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Though the schema already documents all parameters (100% coverage), the description adds essential semantics: the distinction between `project` and `project_name` (id vs name, create-or-find behavior), and the requirement to send current file contents. The binary encoding caveat is reinforced in both places, making the parameters impossible to misuse.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Publish a site to Layero'. It explicitly differentiates from siblings by stating it accepts ANY ready static bundle and is the answer to 'deploy my site', while build-step projects are excluded. This makes the tool's scope unmistakable.

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

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

Provides explicit 'when to use' ('this takes ANY ready static bundle') and 'when not to use' with concrete alternatives: build-step projects should publish build output or use `npx layero@latest deploy`. It also clarifies when to pass `project` for republishing, giving clear decision guidance.

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

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

Annotations already mark readOnlyHint and openWorldHint, but the description adds significant context: it returns a structured object not raw HTML, explains the context-saving rationale, and discloses the served_fallback=true edge case (missing page serving index.html with 200). This goes well beyond the annotations and helps interpret results correctly.

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

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

Four short paragraphs, each serving a distinct purpose: what the tool returns, when to use it, why it returns structure, and the fallback warning. Every sentence is informative; the opening line immediately states the core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that fetches live pages, the description covers the return format, usage timing, the reason for structured output, and an important failure mode (served_fallback). The output schema exists to document exact fields, so the description appropriately focuses on context and interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with detailed descriptions: path includes examples and clarifies it's not a file, project explains slug vs id and how to find the slug. The tool description itself does not add parameter-specific guidance, but with full schema coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Что на самом деле опубликовано: заголовки, тексты, формы, мета, ссылки' — a clear statement of what the tool reads and returns. It distinguishes itself from raw HTML and from sibling tools by focusing on the actual served page content, not disk files.

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

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

It explicitly instructs when to use the tool: 'Зови это ПЕРЕД тем, как что-то править на живом сайте, и ПОСЛЕ публикации' — before editing and after publishing. It also provides a rationale (disk vs served content mismatch) and indicates that for raw source, the user's disk is the alternative.

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

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

The annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces both: it returns modified HTML without publishing, and states 'Преобразования идемпотентны: повторный вызов ничего не меняет и честно отвечает changed=false.' The description also reveals the changed=false contract and the empty-change-list semantics ('Пустой список изменений — не ошибка'), adding valuable behavioral detail beyond what the annotations convey. It doesn't contradict annotations.

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

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

Well-structured: each paragraph earns its place — purpose, idempotency contract, exclusion list, and measurement guidance. Uses bold ⚠️ callout for the critical exclusion section. Informative without padding; every sentence conveys a distinct fact about tool behavior or usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter tool with full schema coverage, an output schema, and rich annotations, the description comprehensively covers the workflow: it explains what the tool returns, how to complete the loop (publish_landing), what it won't fix, and how to interpret performance results. The interplay with check_performance, site_issues, and publish_landing is fully specified, which is complete for the operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters (html = file contents, fix = enum with per-value explanations). The description adds context about what each fix does (e.g., lazy_images skips the first image due to LCP) by referencing the schema's fix description. The description doesn't add new parameter-level semantics beyond the schema, which is the baseline for full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a crisp statement: 'Одно названное преобразование разметки — с предсказуемым результатом.' It names the specific verb (refactor/apply transformation) and resource (site markup), and enumerates exactly what transformations exist (meta, lazy_images). The strong negative framing — 'НИЧЕГО НЕ ПУБЛИКУЕТ' — distinguishes it clearly from publish_landing and site_issues siblings.

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

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

Explicit when-to-use guidance: use it for named markup transformations, and explicitly directs the agent to call publish_landing after human approval. It also gives a clear exclusion list — fonts from third-party hosts, webp re-encoding, inline-style parsing — and points to site_issues for those. It even explains when NOT to report success (measurement noise <3 points via check_performance).

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

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

The annotations only provide openWorldHint=true, so the description carries the behavioral burden, and it delivers: states that the platform will reject running builds (not an error but protection), and warns that retrying code-failures will produce the same result. It doesn't mention the return format, but the output schema exists to cover that.

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

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

Three tight paragraphs: one-sentence core action, explicit state constraints, and a decision-guiding scenario. Every sentence earns its place with no filler. The warning emoji and structured flow (diagnose→fix→retry) make it scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema covering return values and full parameter coverage, so the description focuses on the critical decision context: which states are valid, what rejection means, and when retrying is futile. It could optionally mention rate limiting or auth, but these are well covered by the existing schema and annotations for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters at 100%, and the description adds practical context: the project parameter's slug explains how to derive it from user-provided site names ('возьми слаг из my_projects'), and the deploy parameter's default behavior (без него берётся самая свежая) is hinted by schema but reinforced. The description adds useful real-world semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource combo ('Поставить упавшую сборку в очередь заново' - put a failed build back in queue), clearly distinguishing it from sibling tools like cancel_deploy, rollback, and diagnose_deploy. It explicitly scopes to failed builds.

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

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

Provides explicit when-to-use guidance: only for builds in 'failed' state, explicitly excludes queued/building states, and explains the platform rejection behavior. Also names the alternative workflow: diagnose_deploy first, then fix, then retry. This is exemplary usage guidance with clear exclusions and alternatives.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, which covers the safety profile. The description adds meaningful context beyond the annotations: the action is reversible ('Действие обратимо') but the time window with the wrong version on the address cannot be recovered. It also adds the important caveat that app platforms (ssr_next, streamlit, gradio, flask) may not support rollback at all — this is behavioral context not captured in annotations. Slight gap: doesn't detail auth permissions needed or rate limits, but the reversibility nuance and app-platform caveat add real value.

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

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

Description is appropriately structured: a single clear purpose sentence, a bolded warning about side effects, reversibility caveat, and then a paragraph about app-platform limitations. Front-loaded with the most critical information (modifies what visitors see). The app-platform paragraph adds length but earns its place with critical behavioral nuance. Slightly long but well-organized with clear section breaks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a destructive, side-effect-heavy operation with no room for under-specification. The description covers: what it does, its reversibility, the irrecoverable consequence, when it fails (app platforms), the required user confirmation protocol, and fallback behavior (suggest rebuilding). There is an output schema present which handles return-value documentation. For a high-stakes mutation tool, this is thorough and complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already well-documented in the schema: project is described as slug or id with guidance to pull slug from my_projects, and deploy is described as the build id with default behavior clarified. The description itself doesn't add parameter semantics beyond the schema, but the baseline of 3 is appropriate given complete schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb+resource: 'Вернуть на живой адрес предыдущую рабочую сборку' (return previous working build to live URL). The title 'Откатить сайт на прошлую сборку' and name 'rollback' are mutually reinforcing, and the description adds concrete behavioral detail about what gets changed (what visitors see). Clearly distinguishes from siblings like retry_deploy and cancel_deploy by specifying it switches to a previous working build on the live address.

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

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

Excellent guidance. Explicitly says to ask the human before invoking unless rollback was explicitly requested ('спроси человека перед вызовом, если он не попросил откат прямо'). Clearly states it modifies what visitors see (a side effect requiring confirmation). Also gives explicit when-to-use-elsewhere guidance: for app platforms (ssr_next, streamlit, gradio, flask) rollback often doesn't work, and instructs the agent to explain failure to the user rather than retry. This is exemplary usage guidance.

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

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

The description adds meaningful behavior beyond the readOnlyHint annotation: it explains that the time series is collapsed into a direction and breakdowns are cut to five, and that conclusions are left to the user. This provides useful context about output shape and interpretation.

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

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

The description is brief (two sentences) and front-loaded with the main purpose. The second sentence is slightly verbose but efficiently explains why the data is simplified. No wasted words, though the tone is somewhat informal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values are covered. The description explains the key data transformations (direction collapse, breakdown limit) which affect how results appear. It lacks comparison to sibling tools, but for a simple read-only analytics tool it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for both parameters ('period' enum with default and 'project' with slug/id guidance). The description does not add any parameter-specific meaning beyond what the schema already provides, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool provides: 'Site traffic: totals, direction and top sources.' This is specific and not a tautology, though it lacks an explicit verb like 'retrieves' or 'lists'. It doesn't explicitly distinguish from siblings, but no other sibling tool is focused on traffic analytics.

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

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

There is no guidance on when to use this tool versus alternatives. The phrase 'in your context' refers to data presentation, not tool selection. No exclusions or references to sibling tools are provided.

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

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

The annotations already declare readOnlyHint and openWorldHint, so the description's safety burden is low. It adds meaningful behavioral details: findings are sorted by importance, output includes a fix action, and the tool explicitly excludes performance scores. This goes beyond the annotations without contradicting them.

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

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

The description is concise yet information-dense: it starts with the core purpose, then clarifies non-overlap with a sibling, gives concrete examples, and ends with usage guidance. Every sentence earns its place, and the structure is logical and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a rich input schema, annotations, and an output schema, the description covers all necessary context: what the tool returns, what it does not return, how results are ordered, and how to present them. It fully equips an agent to decide when to invoke the tool and what to do with the results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with clear descriptions for both `path` and `project`. The description does not add parameter-specific details, but it does mention 'each with an address' which relates to the path concept. Given the schema's completeness, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides specific page problems, each with an address and an actionable fix. It explicitly contrasts itself with check_performance ('This is NOT a score') and lists concrete examples, making its purpose unmistakable and differentiating it from siblings.

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

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

The description explicitly name-drops check_performance and distinguishes when to use each ('the score is given by check_performance, and there is nothing to fix based on it'). It also gives presentation guidance ('Don't dump them as a list—name two or three main ones and ask'), which is actionable usage direction.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context beyond annotations: the snapshot is made at BUILD time, not at call time, so it may be stale after publishing. This 'синимок делается при СБОРКЕ, а не сейчас' disclosure is a critical behavioral trait that prevents the agent from misattributing an outdated screenshot to its own edit. It also discloses cost characteristics. Minor deduction because it doesn't mention response format or caching details beyond build timing.

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

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

The description is well-organized: a clear first sentence stating purpose, then related-tool framing, then two important behavioral warnings with formatting. It's slightly longer than strictly needed due to the two warning paragraphs, but every sentence earns its place — both warnings (build-time staleness, cost) are critical behavioral context. Strong structure with clear paragraphs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

As a simple read-only tool with one well-documented parameter and no output schema, the description covers the critical operational caveats (build-time snapshot, cost) and position among siblings. The warning about not passing off a stale screenshot as one's own result is particularly valuable for agent behavior. Near-complete for this tool's complexity; slight deduction only because it doesn't describe the image return format or how large the response might be beyond a generic cost warning.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'project' parameter is well-documented in the schema itself (slug or id, with guidance on deriving slug from my_projects). The description adds value by framing the tool's purpose contextually. Baseline 3 applies with full schema coverage, but the description enriches the conceptual meaning of the tool, though it doesn't add extra parameter detail beyond schema. The project param is thoroughly covered, so 4 reflects the adequate but not necessary additional param info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool shows a snapshot of the last built version of the site and how it looks. The verb 'показать снимок' (show screenshot) is specific, the resource is explicit (site), and it differentiates from siblings read_site and site_issues by naming them and clarifying the unique question it answers: 'how it looks visually'.

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

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

The description explicitly names sibling tools and the distinct questions each answers ('что на странице' for read_site, 'что с ней не так' for site_issues, 'как это смотрится' for this tool). It also gives clear when-to-use guidance (before/after editing styling) and cost guidance with an explicit alternative: 'сайт есть site_issues, он дешевле и конкретнее'. This is exemplary alternative-naming and when/when-not guidance.

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

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

Annotations provide readOnlyHint=true, and the description adds behavioral context beyond that by explaining the tool aggregates project info, deploys, and live address checks into a single conclusion. This gives the agent insight into the tool's consolidated nature without contradicting the read-only annotation.

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

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

The description is two sentences: the first front-loads the core purpose, the second succinctly explains the parameter and the benefit of a consolidated call. Every sentence earns its place with no redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter, full schema coverage, an output schema, and a readOnly annotation, the description provides all necessary context for an agent to select and invoke the tool. It even cross-references my_projects for slug resolution, making it self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a detailed parameter description for 'project' (id/slug, how to obtain slug from my_projects). The description repeats the id/slug point but does not add new meaning beyond the schema, so it meets the baseline but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reports site status ('whether it is being served and how its build ended') and distinguishes itself from more granular sibling tools by consolidating three separate calls (project, deploys, live check) into one. The first sentence is a specific verb+resource combination.

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

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

The description explicitly frames usage: 'One call instead of three... an agent needs the conclusion, not the raw material to assemble it from.' This tells the agent when to use the tool (when a high-level status summary is needed) but does not name specific alternative tools or state when not to use it, so it lacks full exclusion guidance.

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

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

Beyond the readOnly and idempotent annotations, the description adds that the tool produces clear errors for misconfigured tokens, which is useful behavioral context for an agent deciding on error handling.

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

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

Two concise sentences: the first states function, the second gives a practical usage hint. No redundant information, perfectly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, clear output), the description fully covers what the agent needs to know. The presence of an output schema further covers return format details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is 100%. With no parameters to describe, the description appropriately focuses on output and usage rather than parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reports the connected entity and project count. This is distinct from sibling tools which focus on domains, analytics, or deployment, making the purpose unambiguous.

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

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

Explicitly instructs to call this tool first when token configuration is uncertain, noting that errors here are cheaper than mid-deploy failures. This provides a clear when-to-use scenario.

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