ui_inspect

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

Annotations already declare readOnlyHint, non-destructive, and openWorld. The description adds a meaningful behavioral trait beyond them: the operation does not open or focus the target, so it is inspection-only with no focus side effects. No auth, rate limit, or return-format detail is given, but the annotations carry the safety profile.

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-loading the read scope and then the alternative routing. Every clause 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?

For a single-param read tool with no output schema, the description covers what is read and the non-intrusive behavior. The main gap is that it does not describe what 'geometry' entails or the shape of the returned state, which would help an agent interpret 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?

Schema coverage is 0% and there is a single parameter 'path' with a default of /main_view. The description implies 'path' refers to a known UI path but does not specify format, syntax, or how paths are obtained, so it only partially compensates for the undocumented 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?

States a specific verb+resource combination: it reads a known UI path's geometry and enabled/visible state, and adds a distinguishing constraint ('without opening or focusing it') that separates it from ui_click/ui_select. It also names sibling ui_find for child discovery, so an agent can tell it apart from neighboring ui_* tools.

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?

Clearly conveys the usage context ('known UI path') and routes to the alternative when you need to discover children ('with scoped ui_find'). It lacks an explicit when-not statement, but the 'known' qualifier effectively excludes exploratory discovery without calling this tool.

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