Clear

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

With no annotations, the description carries the full burden. It does disclose one valuable behavioral trait — the default scope of 'both screens unless display is given' — and the word 'temporary' hints that persistent elements survive. However, it omits whether the clear is irreversible, whether it can remove content set by other apps, and what happens to in-flight animations.

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, no redundancy, and the scope default is stated immediately after the action. The only weak spot is the vague prepositional phrase 'from the MCP', which costs a word without adding precision.

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 one-optional-parameter, no-output-schema tool this is close to adequate: it says what is removed and what scope is used by default. It falls short on the destructive scope question — what exactly gets wiped — which matters for an unannotated clear operation.

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 compensate for the single 'display' parameter. It does partially: it establishes that omitting the parameter targets both screens, which the enum alone does not convey. It adds no clarification of front vs back semantics beyond the literal enum values.

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 and resource: 'dismiss temporary overlays and drawings'. That distinguishes it from the additive siblings (bar_text, bar_pixels, bar_image) which draw content rather than remove it. The phrase 'from the MCP' is ambiguous (device? MCP-managed layer?) and slightly muddies an otherwise clear purpose.

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: an agent infers it should call this to remove overlays. There is no explicit when-to-use/when-not guidance, no mention of whether it should be called before drawing new content, and no reference to siblings like bar_status or busybar_return_to_auto that might overlap in resetting display state.

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