run_project_verification

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully discloses that only allowlisted npm scripts can be run and that arbitrary commands are rejected, which is important safety-relevant behavior. However, it does not mention whether the script may modify files, what output or exit codes are returned, or any permission/prerequisite requirements, leaving notable transparency gaps for an execution tool.

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 two sentences with no wasted words. The opening sentence states the core function, and the second adds a critical constraint. It is front-loaded and appropriately sized for the tool's simplicity.

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 no annotations and no output schema, the description is not complete enough. It does not state the return/output behavior, how to identify the project, whether side effects occur, or how this tool relates to similar sibling tools like bakugun_run_quality_suite. An agent would still need to infer or guess several operational details.

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 clarifies that scripts are npm verification scripts and only allowlisted ones, but it does not explain what the `project` parameter refers to (path, workspace name, etc.) or each enum value's meaning beyond its name. This is minimal value beyond the raw schema.

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 clearly states the tool's action ('Run one allowlisted npm verification script') and its scope ('in a project'). It also explicitly distinguishes it from arbitrary command execution, which sets it apart from possible generic execution tools and clarifies its niche relative to sibling tools like bakugun_run_quality_suite.

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 clear context for when to use the tool: when you need to run a verification script that is on the allowlist. The phrase 'Arbitrary commands are not accepted' provides an exclusion, telling users not to use it for non-allowlisted commands. However, it does not name alternatives like bakugun_run_quality_suite or get_project_status, so it falls short of the full when/alternatives guidance.

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