uprof_check

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

The description goes far beyond the readOnlyHint annotation by detailing the `mode` values ('real', 'mock', 'unavailable') and their implications. It discloses that mock mode produces fabricated numbers for testing, and that unavailable mode includes fix notes. It also surfaces the CPU-specific limitation, which is crucial behavioral context for downstream tool invocation.

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 concise and front-loaded: the first sentence states the purpose, and the following sentences elaborate with essential details about modes and compatibility. Every sentence adds value—no filler or redundant restatement of the tool name. The structure is logical and scannable.

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 zero-parameter environment probe with an output schema, the description is thorough. It explains the key output fields (mode and available_analyses), provides guidance on when to call it, and includes a hardware caveat. The context signals show high schema coverage and a rich output schema, but the description still adds meaningful context beyond what structured data provides.

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 has zero parameters, so the input schema is empty and the description cannot add parameter-specific meaning. Per the rubric, a 0-param tool receives a baseline score of 4, which is appropriate here. The description does mention output fields (`mode`, `available_analyses`) but these are return values, not 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?

The description opens with a specific verb ('Probe') and resource ('uProf environment') followed by a clear list of outputs (binary, version, platform, active mode, results dir). This distinguishes it from sibling tools like uprof_collect (collects data) and uprof_report_* (reports on collected data), making its purpose 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 explicitly says 'Call this before collecting,' establishing it as a prerequisite for collection tools. It also explains that `available_analyses` feeds into uprof_collect and notes a hardware limitation (only 'tbp' works on non-AMD CPUs), which helps an agent decide when and how to use the information. It does not explicitly name alternatives, but the sequencing guidance is clear and actionable.

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