mimicus_verify_implementation

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

Annotations declare openWorldHint=true, idempotentHint=false, and readOnlyHint=false, so safety/idempotency signals are already covered. The description adds that it compares across matching viewports and reports differences/tolerances rather than asserting identity, which is useful scope framing. It does not explain what artifacts or state changes the non-read-only operation produces.

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 tightly packed sentences with the operative verb and comparison scope front-loaded and no filler. The abstracts ('authorized open implementation', 'selected temporary reference evidence') cost some clarity, but nothing is wasted.

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 need not be described. For a six-parameter, cross-session comparison tool with an output contract in hand, the description covers intent and result semantics adequately but leaves parameter meaning and sibling selection entirely to inference.

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 0% across six parameters, so the description carries the full explanatory burden and it names none of them (selector, analysisId, targetSessionId, referenceSessionId, componentId, scrollContainer). Phrases like 'matching viewports' and 'temporary reference evidence' gesture at the session-pairing concept but give no mapping to specific inputs.

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?

States a specific verb and resource: reobserve an open implementation and compare it against temporary reference evidence across matching viewports. The closing clause ('Report differences/tolerances rather than claiming visual identity') sharpens what the tool produces. It never differentiates itself from the nearby sibling mimicus_compare_references, so the purpose is clear but not fully disambiguated.

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?

Usage is implied through prerequisites ('authorized open implementation', 'selected temporary reference evidence'), which tells the agent sessions and reference evidence must already exist. However, there is no explicit when-to-use statement, no exclusions, and no guidance on choosing this over mimicus_compare_references or mimicus_get_implementation_spec.

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