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.