perf

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

With no annotations, the description carries the behavioral disclosure burden. It states that profiling output is evidence only with compact state, artifact path, and size, and discloses the 90-second timeout. It also clarifies the raw-artifact vs. summary behavior for CPU profiling, though it leaves sample/snapshot specifics and any side effects of starting a profile somewhat 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?

The description is compact and front-loaded: it opens with the tool's core purpose, then adds action guidance, output expectations, and the timeout. Every sentence contributes useful information with minimal 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?

The description covers output shape and timeout, which is important since there is no output schema. However, this tool has 23 parameters and no annotations, and the description does not cover area/kind/action interactions, default behavior, or device/tenant resolution context. It is adequate for common CPU profiling use but leaves notable gaps for memory, frame, and trace workflows.

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 high at 83%, so the baseline is 3. The description adds meaning beyond the schema by explaining how action values start, stop, and report behave for CPU profiles, and by tying output to artifact paths and compact summaries. It does not fully explain all action variants like sample or snapshot, but the added action semantics are valuable.

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 uses a specific verb and resource: 'Collect frame health, memory diagnostics, and platform profiling artifacts.' It clearly identifies the tool's domain and distinguishes it from generic UI or device tools like screenshot, click, and trace by focusing on profiling evidence and compact summaries.

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 gives concrete guidance for CPU profiles: start and stop write the raw artifact while report writes a compact summary, and the report should be requested when readable native CPU evidence is needed. It does not name alternative tools explicitly, but it provides clear in-tool action selection guidance.

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