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

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context beyond that: it runs headlessly on a VM with jsdom, details the testing environment limitations, explains that @floot/* modules are skipped, and describes the output format (per-file PASS/FAIL). This transparency helps the agent anticipate side-effects and constraints without contradicting the annotations.

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 fairly long but densely packed with useful information. It front-loads the core action and then logically covers scope, limitations, and customization. Every sentence adds value, though it could be slightly more structured (e.g., bullet points). The length is justified by the tool's complexity, so it earns a 4 rather than a lower score.

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?

Given the tool's complexity (test execution, environment constraints, multiple spec types), the description covers all essential aspects: what runs, how it runs, what to expect (PASS/FAIL), default exclusions, and how to override. It lacks an output schema but compensates with descriptive output information. An agent would know exactly what to do and what to expect, making this complete.

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 both parameters. It explains 'paths' well ('pass paths to run specific spec files') and implies that projectId identifies the project. However, it does not explicitly describe projectId's format or purpose, leaving some ambiguity. Since the tool is project-specific, projectId is likely obvious, but the description could be more explicit. Given the limited compensation, a score of 3 is fair.

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 states a specific verb ('run') and resource ('Jasmine spec files'), with precise scope ('helpers/*.spec.tsx', headlessly on VM with jsdom). It clearly distinguishes itself from siblings like run_code_in_vm or typecheck by focusing exclusively on test execution. The title and name align, and the description leaves no ambiguity about the tool's function.

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 provides explicit guidance on when and how to use the tool: defaults to all spec files except hook specs, pass 'paths' to run specific files including hook specs. It also explains constraints (fetch throws, no env secrets, @floot/* skipped) that inform usage decisions. This is thorough and actionable, covering both default behavior and overrides.

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