Probe the executable

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

The description asserts 'Read-only,' while the annotations declare readOnlyHint=false — a direct contradiction of a declared safety property, which the rubric treats as a score of 1. The valuable behavioral detail it does add (the binary can block forever on a modal dialog, and the probe is idempotent per the annotation) is undercut by the conflicting safety claim, which could lead an agent to skip the timeoutMs guard.

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?

Three sentences, and the operative command and the pre-flight rule are front-loaded, which is good structure. However, the middle sentence ('Read-only and project-independent') is both the source of the annotation conflict and less load-bearing than the timeout/modal-dialog warning that follows it.

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 four-parameter, zero-required probe with no output schema, the definition covers the invocation, the working-directory expectation, the failure mode it exists to catch, and the default timeout. The remaining gap is what a successful probe yields back to the agent (version string vs. exit status), which matters for deciding whether to proceed to a compile.

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 100%, so the baseline is 3, but the description adds semantics the schema does not carry: why cwd matters (MAX+PLUS II expects to run in the project directory) and that mode maps to the -v/-h flags. It does not explain what distinguishes the version and help probes behaviorally, but the extra project-layout context is real value.

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 and the exact underlying command: run `maxplus2 -v` (or -h) to verify the binary starts and returns. It also distinguishes scope ('project-independent') and separates itself from the compile-loop siblings like maxplus2_run by positioning itself as the prerequisite gate.

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?

Gives a clear conditional trigger: 'Run this before trusting any headless compile loop,' with a rationale (blocking on a modal dialog) that tells the agent when the probe is worth the call. It stops short of naming the alternatives it should precede or stating when it is unnecessary, so it falls just under a 5.

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