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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, so the agent already knows this mutates page state and interacts with a live page. The description corroborates with 'controlled interaction' and adds useful non-obvious context that it returns direct evidence without persisting a pattern repository, but it omits what the interaction actually alters and any repeatability/caching behavior.

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 tight sentences, front-loaded with the core action and scoped by an enumeration of the notable capabilities. No filler, though it is arguably too terse given seven undocumented parameters.

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 explained, and the non-persistence note is a helpful differentiator. However, with 7 parameters at 0% schema coverage and no annotations explaining side effects, the description is thin for the tool's complexity and leaves required-parameter intent unclear.

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%, so the description carries the full burden, and it only hints at three of seven params (trigger via 'controlled interaction', scrollContainer, viewports). It omits the required sessionId and selector plus probeReset and reducedMotion, leaving meaningful gaps despite the partial 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?

States a specific verb+resource ('Measure a selected component in the active page') and enumerates its scope: controlled interaction, scroll container, responsive viewports. It is distinguishable from page-level siblings like mimicus_explore_page and mimicus_capture_view, though it never names them explicitly.

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 explicit when-to-use guidance, no statement of when to prefer this over mimicus_interact, mimicus_capture_motion, or mimicus_explore_page, and no prerequisites or exclusions. The phrase 'optional controlled interaction' implies you may trigger events, but the selection criteria remain unstated.

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=false, idempotentHint=false and openWorldHint=true, so the agent knows this operation writes/refreshes state in an open world. The description adds useful color consistent with that profile: fetching produces a "fresh" view (explaining the non-idempotent write) and normalized concepts are separately labeled. It does not contradict the annotations, but adds only modest context beyond 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?

Two short sentences with no filler, and the dual mode (explore vs. fresh view) is stated up front. The wording is dense with internal jargon, but nothing is padded or repetitive.

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 with two undocumented parameters, no required-parameter signal, and no usage guidance, the description is too thin. Output schema exists so return values need not be explained, but the agent still lacks the plain-language purpose and parameter meaning needed to 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 0%, so the description must carry the parameter burden. "source-native" and "active operation" only obliquely gesture at the provider enum and operationId; neither parameter is named, explained, or given format expectations, leaving both effectively undocumented.

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?

"Explore source-native taxonomy" is essentially a jargon paraphrase of the name browse_categories, and "fetch a fresh bounded source view" is equally opaque. No concrete noun like "categories/tags for a source" is used, so an agent cannot quickly confirm the resource being enumerated, and no sibling (e.g. mimicus_list_sources, mimicus_search) is distinguished.

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 phrase "in an active operation, or fetch a fresh bounded source view" gestures at two modes but never states the condition that selects one over the other, nor when this tool should be used instead of mimicus_list_sources or mimicus_search. It is implied context at best, with no 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=false, idempotentHint=false, openWorldHint=true, so the agent knows this is a non-idempotent, world-touching operation. The description usefully adds that only one 'safe' interaction is applied between frames, but leaves 'safe' undefined and doesn't describe side effects on page or session state. No contradiction with 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?

Two tight sentences with the core action front-loaded and the scope exclusion second. No filler, though the second sentence is a negation rather than a routing rule.

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?

Output schema exists so return values needn't be explained, but a complex tool with a nested interaction schema and zero parameter documentation is under-served. The description gives no frame/interval semantics or interaction-object detail needed to call 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 0% across 5 parameters, including a deeply nested interaction object with 13 sub-properties and enums. The description gestures at 'timestamped images' and 'one interaction' but never explains frames, intervalMs, selector, or sessionId, so it does not compensate for the coverage gap.

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 (capture) and resource (a selected effect as timestamped images), which is clear and distinguishable from a static-capture sibling like mimicus_capture_view. The scope qualifier 'No automatic whole-site recording' sharpens the boundary, though no sibling is named explicitly.

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?

Implies usage context (motion/effect capture with an optional interaction) and gives one exclusion ('No automatic whole-site recording'), but never states when to prefer this over mimicus_capture_view or mimicus_interact. Guidance is inferable 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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds genuinely useful context beyond them: output arrives as MCP image content and no persistent screenshot file is written, clarifying the transient, side-effect-free nature of the call.

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?

A single front-loaded sentence that leads with the action and result before adding the non-persistence caveat. Every clause earns its place; the semicolon clause is slightly run-on but not wasteful.

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, the description need not restate the return format, and it usefully notes the image-content behavior. However, for a tool requiring a sessionId it omits session prerequisites, selector semantics, and failure behavior, leaving notable gaps for a 2-parameter 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?

Schema description coverage is 0%, so the description must carry the burden for both parameters, but it never names sessionId, selector, or their expected formats. 'Bounded selected-region' hints at the selector and the viewport default hints at its absence, but neither is tied explicitly to a parameter.

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 gives a specific verb and resource: it returns a viewport or selected-region screenshot as MCP image content. This separates it from siblings like mimicus_capture_motion, though it never names that sibling explicitly, so differentiation is inferred rather than stated.

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 explains what the tool produces but gives no when-to-use guidance, no prerequisites (e.g. an active session), and no mention of alternatives such as capture_motion or analyze_element. The agent must infer usage entirely.

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 real behavioral context beyond the annotations by naming what is torn down and clarifying that only temporary page and analysis state is released. It does not contradict the annotations (destructiveHint=false is defensible for session cleanup), but it also doesn't cover what happens on a repeat call despite idempotentHint=false, or whether results become unrecoverable.

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?

One front-loaded sentence with no filler; the only minor cost is the compressed 'browser/context/proxy' slash list, which reads slightly less clearly than prose but is still economical.

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 no explanation, and the single-parameter surface is narrow. Still missing are the conditions under which the call is valid and what the caller should do with results after the analysis state is released, leaving it adequate but not fully 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 description coverage is 0% and the sole parameter sessionId is never referenced in the description, so the description contributes nothing beyond the schema's type and length constraints. The low coverage means the description should have compensated but does not.

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 (close) plus the concrete resources torn down (browser/context/proxy) and the side effect (release temporary page and analysis state). It is clear what the tool does, though it does not distinguish itself from the teardown-flavored sibling mimicus_end_discovery.

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 explicit when-to-use statement, no prerequisites (e.g. must the session be open?), and no guidance on how this differs from mimicus_end_discovery, which also sounds like an ending operation. Usage is only inferable from the name.

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=false, openWorldHint=true, idempotentHint=false and destructiveHint=false. The description usefully adds output semantics ('no aesthetic winner is inferred'), but for a non-read-only, non-idempotent operation it never explains what side effect is produced or what state it changes, leaving a meaningful gap the annotations don't cover.

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 sentences, front-loaded with the core action, with no obvious filler. The second sentence is dense and jargon-heavy but still earns its place by naming the synthesized outputs.

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, but for a tool with a complex nested required brief at 0% schema coverage the description is too abstract to guide correct invocation. It leaves the brief's field semantics and the session-count constraints unexplained.

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% and the 'brief' parameter is a nested object with multiple required fields (project, audience, primaryAction, sections). The description gestures at both parameters ('selected open references', 'a project brief') but adds no meaning about the brief's required fields, the 2-3 sessionIds limit, or the anchorSessionId, so it does not compensate for the coverage gap.

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 a specific verb and resource ('Compare selected open references with actual images and measured insights') and adds that a brief synthesizes composition, navigation and motion guidance. It distinguishes the tool from read-only siblings like get_reference or search, though the exact output artifact remains somewhat abstract.

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 only implied: the tool operates on 'selected open references,' suggesting open_reference must precede it, and a brief is optional ('Supply a project brief to...'). There is no explicit when-to-use versus alternatives, no exclusions, and no stated prerequisite that references must already be open.

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 the full safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true). The description adds real value by disclosing the cascade: both the operation and its candidates/cursors are released, not just the operation handle. It omits whether the released candidates are recoverable and what happens on a second call, which the non-idempotent hint makes relevant.

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?

A single front-loaded sentence with no filler; the scope of the release ('and its candidates/cursors') is stated compactly. It is arguably too terse for a non-idempotent teardown tool, 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 explained, and annotations cover safety. What remains missing for a lifecycle/cleanup tool is the prerequisite state ('selected' operation), the relationship to mimicus_close_session, and what happens post-release. Adequate but with clear 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?

One required parameter at 0% schema description coverage, so the description must carry the burden. 'The selected temporary discovery operation' weakly implies operationId comes from a prior selection step, but gives no format, source, or constraint guidance (the schema's 1-100 length bounds are undocumented anywhere).

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: 'Release the selected temporary discovery operation' plus its 'candidates/cursors', which an agent can map to the mimic discovery lifecycle. It does not, however, distinguish itself from the sibling mimicus_close_session, leaving ambiguity about which teardown tool applies to which resource.

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 when-to-use, no preconditions (an operation must already be open/selected), and no mention of the obvious alternative, mimicus_close_session. The word 'selected' implies prior state but the agent is given no guidance on when ending discovery is appropriate versus closing a session.

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 frames the tool as a pure inspection ("Find", "inspects only the selected open page"), while the annotations declare readOnlyHint=false and idempotentHint=false, i.e. an operation that may mutate environment/session state and is not safely repeatable. The description supplies no side-effect, permission or repeat-call context and never reconciles that mismatch, so an agent could wrongly treat it as a free, repeatable read.

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 tight sentences, front-loaded with the action and its payload, followed immediately by the scoping constraint. No filler or restated name/title; every clause carries 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?

An output schema exists so return values need not be described, but for a four-parameter, zero-schema-coverage tool the description leaves the agent guessing on pagination and filtering, and leaves the read/write semantics unresolved against conflicting annotations. That is not enough to call it confidently.

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%, with all four parameters (sessionId, limit, offset, visibleOnly) undocumented, so the description must carry the load. "Current" and "the selected open page" loosely gesture at the session/page scope and the notion of currently-visible content, but pagination (limit/offset, max 50/500) and the visibleOnly filter are entirely unexplained.

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 (find) over a specific resource set (semantic sections, navigation, controls) and names the payload returned (geometry, selectors), so the agent knows exactly what kind of artifact it gets. It does not distinguish itself from close siblings such as mimicus_capture_view, mimicus_analyze_element or mimicus_search, which an agent must choose between for the same page.

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?

"This inspects only the selected open page" gives an implicit precondition and scope boundary (a page must already be open and selected), which usefully rules out cross-page/cross-tab exploration. It never says when to prefer this over the sibling capture/analyze/search tools, so selection still requires 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?

Annotations declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, which is counterintuitive for a 'get'-style tool; the description does not explain why repeated calls are non-idempotent or that it operates against live external page state. It does add useful output semantics by separating 'measured observations' from 'separately labeled original guidance', which tells the agent how to interpret the response.

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?

One dense but front-loaded sentence that leads with the verb and the concrete payload; nothing is wasted. The trailing 'alongside its real visual reference' clause is slightly convoluted but does carry 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?

An output schema exists, so return-value mechanics are covered, and the annotations carry the safety profile. However, for a non-idempotent, open-world tool the description omits prerequisites, expected session state, and any differentiation from the reference/analysis siblings, leaving meaningful 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?

Schema description coverage is 0% for the single required sessionId parameter, so the description must compensate. It partially does by tying the call to 'the selected live page', implying the session selects the target, but it never explains the sessionId's role or its relationship to session/page selection.

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 names a specific verb ('Return') and a precise resource: measured layout, palette/spacing/typography/navigation/animation observations plus separately labeled original guidance and a visual reference, scoped to 'the selected live page'. That is far more concrete than a generic 'get insights', though it never names which sibling it supersedes (e.g. mimicus_get_reference, mimicus_analyze_element).

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 when-to-use or when-not-to-use guidance and no stated prerequisite beyond the implicit requirement that a page already be selected in the session. With 15 sibling tools including get_reference, analyze_element and explore_page, the agent is given no criterion for choosing this one over them.

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/idempotentHint and non-destructiveness, so the description does not need to restate safety. It adds genuine context beyond them: the dependency on an active session, the ephemeral nature of the 'temporary analysis', and the fact that no globally stored pattern ID can be used. Return format and error behavior are left implicit.

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 compact sentences with zero filler, and the core purpose is front-loaded ahead of the prerequisite constraints. Nothing redundant is present.

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 no explanation, and annotations carry the safety profile. What remains missing is any differentiation from sibling retrieval tools and any semantic description of the optional componentId, so the definition is adequate but not fully 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 coverage is 0%, so the description must compensate. It explains two of three parameters implicitly ('active session' for sessionId, 'a selected temporary analysis' for analysisId), which is useful, but the optional componentId is never mentioned and no format or scoping detail is provided for any parameter.

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 names a specific verb ('Get') and a concrete resource ('actionable measured constraints and original implementation guidance') drawn from 'a selected temporary analysis'. It is clear what the tool returns, though it never distinguishes itself from close siblings such as mimicus_get_design_insights or mimicus_verify_implementation.

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 states a prerequisite ('Requires an active session') and a usage constraint ('there is no global stored pattern ID'), which hints that the ID must be session-scoped. However, it names no alternative tool and gives no explicit when-to-use vs when-not guidance, leaving selection between this and sibling insight tools 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context beyond those: it returns source-native classifications, original URLs, provenance and remote preview links, and explicitly states there is no disk snapshot fallback. That fallback disclosure is the kind of trait annotations cannot express.

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 compact sentences with no filler, and the core action leads. The second sentence is terse and slightly cryptic, but nothing is redundant.

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 needn't be spelled out — yet the description spends its budget enumerating return content rather than the two undocumented required parameters. For a read-only retrieval tool this is workable but leaves a real gap around the identifier semantics.

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% for two required string parameters (operationId, referenceId), so the description carries the full burden of documenting them. It mentions neither, leaving the agent with no explanation of what an operationId or referenceId is, where they come from, or whether the reference must belong to the active operation.

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 ('Retrieve') and resource ('an active discovery candidate'), scoped to 'active' candidates, and the added clause 'No disk snapshot fallback' implicitly separates it from a cached/snapshot variant. It is clear what the tool does, though sibling names like mimicus_open_reference are not explicitly differentiated, so the agent must infer the boundary.

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 when-to-use guidance: nothing says when to prefer this over sibling tools such as mimicus_open_reference, mimicus_explore_page, or mimicus_search. The 'No disk snapshot fallback' clause implies a boundary condition but does not name the alternative or the situation that selects 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?

Annotations cover the safety profile (destructiveHint=false, openWorldHint=true), and the description corroborates with 'non-destructive click' and 'Safely explore'. It adds real value beyond the annotations by disclosing scope constraints an agent would otherwise not know: navigation is restricted to 'same-origin reviewed' targets, and the call returns the resulting real image. It stops short of describing session lifetime, failure behavior, or why idempotentHint=false matters.

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 compact sentences, with the core purpose and safety constraint front-loaded and the return value appended. No filler or repetition of the tool name.

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 explained at length, but the tool has a large nested parameter surface at 0% description coverage and the description only partially compensates. Session prerequisites and per-action parameter expectations are missing for what is a stateful, open-world interaction 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?

Schema description coverage is 0% and the nested interaction object has 11 enum actions plus x/y, selector, viewport, endX/endY, steps, waitMs, key and url. The description recovers roughly two-thirds of the action vocabulary (hover, focus, click, scroll, pointer, navigate, key, resize/viewport, reducedMotion) but omits touch, drag and wait, and says nothing about selector, coordinates, or step semantics.

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 (interact/explore) plus resource (a selected page) and enumerates the supported interaction kinds, so the agent knows this is the action-performing tool rather than the capture or analysis ones. It does not, however, distinguish itself explicitly from close siblings like mimicus_explore_page or mimicus_capture_view, which is the only thing keeping it from 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?

'Safely explore a selected page' and 'a selected page' imply this tool is used after a page has been selected/opened, but no prerequisites (session creation), ordering relative to siblings, or when-not-to-use conditions are given. Usage is inferable from context rather than stated.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — that a descriptor reflects a snapshot rather than a live connection — but it is worded so opaquely that its practical implication for the agent is uncertain.

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?

It is short and front-loads the verb, but the first sentence packs five undefined jargon items into one clause and the second is an unexplained aphorism. Sentence count is fine; clarity per sentence is not.

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 needn't be explained, and annotations cover the safety profile. What remains missing is any grounding of the core vocabulary ('adapters', 'sources') and any hint of how this fits with its many siblings, leaving the definition minimally viable but ambiguous.

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 takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies since no parameter-level detail is 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 verb 'List' is specific and the description enumerates the kinds of content returned (adapters, diagnostics, interfaces, restrictions, resource state). However, terms like 'adapters' and 'sources' are never grounded, so an agent cannot tell what domain this operates on, and no sibling tool is referenced for differentiation from tools like mimicus_search or mimicus_get_reference.

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 statement of when to call this versus the 15 sibling tools, no prerequisites, and no exclusions. The closing sentence ('An unqueried descriptor is not a live connection') is a cryptic caveat, not 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?

Annotations already declare openWorldHint=true, non-readOnly, non-idempotent, non-destructive. The description adds meaningful context beyond them: the session is an isolated temporary Chromium instance, the return is an actual screenshot as image content, and additional resource origins require approval. It still doesn't explain session lifetime or how the session is torn down.

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 written sentences with the core action front-loaded and the input constraint following. No filler, though the approval note is slightly compressed and could be clearer.

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 output schema covers return values and annotations cover the safety profile, so those burdens are lifted. However, for an 8-parameter tool with nested viewport objects and 0% schema coverage, the description omits too many parameters to be fully complete for correct 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 0% across 8 parameters, so the description must carry the full semantic load. It only implicitly covers url, the reference pair (referenceId/referenceUrl), and resourceOrigins; viewport, reducedMotion, operationId, and the meaning of the required 'authorized' flag are left completely undocumented. Significant compensation gap.

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 (open) plus resource (an authorized original site) and the concrete outcome (return its actual screenshot as MCP image content), which is more than a restatement of the name. It does not, however, explicitly distinguish itself from close siblings like mimicus_capture_view or mimicus_get_reference, so an agent must infer the boundary.

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 phrase 'Supply either a live reference pair or an explicit original URL' gives implicit conditions for calling (you need a reference pair or a URL). But it never states when to prefer this tool over mimicus_capture_view / mimicus_get_reference, and there are no explicit exclusions. Usage is implied rather than directed.

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 declare readOnlyHint=false, idempotentHint=false and openWorldHint=true; the description adds meaningful context beyond those flags by explaining that a new search fetches fresh data while operationId continues a bounded RAM-only operation, and that native labels and computed similarity stay distinct. This explains the non-idempotent, stateful character of the tool. It still omits why a search is flagged non-read-only and says nothing about rate limits or failure behavior.

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, purpose front-loaded, with no filler. The final sentence ("Native labels and computed similarity remain distinct") is somewhat cryptic, but overall the description is compact for a 16-parameter tool and every sentence carries 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?

An output schema exists so return values are covered, and safety hints come from annotations. However, for a 16-parameter, zero-required, zero-description-coverage tool, the description supplies almost no parameter or selection guidance, which is the largest information gap an agent faces here.

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 16 parameters, so the description carries the full explanatory burden and largely fails. Only operationId semantics are explained; retrieval modes (lexical/hybrid/semantic), providers, query, limit, sourceSort and the remaining ten parameters are never mentioned, leaving the agent to guess at intent and valid combinations.

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?

"Find current design references from the seven live source indexes" gives a specific verb (find), resource (design references), and scope (seven live source indexes). It is clearly a retrieval tool, but it never contrasts itself with the closest siblings (mimicus_browse_categories, mimicus_list_sources, mimicus_explore_page), so an agent still has to infer which retrieval entry point applies.

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 second sentence does give a genuine usage rule: start a new search for fresh data, or pass operationId to continue an existing bounded operation. That is real conditional guidance, but there is no statement of when to prefer this tool over the many sibling browsing/discovery tools, and no 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 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.