quest_perf_session

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

With no annotations, the description carries full transparency responsibility. It discloses the max duration (300s), what data is collected (per-second VrApi metrics, memory anatomy, thermal timeline), that a JSON file is saved and its path returned, and the default app behavior. This is substantial behavioral context, though it does not mention potential side effects like storage consumption or performance overhead during recording.

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: the first sentence states the core action and expected return, followed by targeted use context, file output details, and the default behavior. Every sentence adds information; the list of diagnosis types is concise yet illustrative. No wasted words.

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 complex session-recording tool with no output schema, the description covers the essential context: what it records, what it returns, the saved file path, the connection to quest_perf_diff, and the defaults. It even hits on practical usage ('Use while the user exercises their app'). There is no obvious missing piece that would leave an agent confused about how to invoke or interpret the 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 compensate. It does add meaning by noting the max session length (300s) and the 'Defaults to the current foreground app' behavior, which hints at package_name/device_id being optional. However, device_id is not explicitly explained, and duration_seconds is only implied by 'max 300s.' The description adds some value but does not fully cover all three parameters.

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 opens with a specific verb-resource pair ('Record a full performance profiling session') and clearly enumerates the tool's deliverables: a summary, a bottleneck diagnosis with evidence/recommendations, and notable events. It also differentiates itself from sibling tools by mentioning the saved JSON file and the link to quest_perf_diff, making its unique role unmistakable.

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 explicit timing guidance: 'Use while the user exercises their app in the headset.' It also clarifies that the tool defaults to the current foreground app, which implicitly tells the agent when parameters can be omitted. It mentions the relationship to quest_perf_diff for comparisons but does not explicitly state when not to use this tool in favor of monitoring or tracing siblings.

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