start_dev_server

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

No annotations exist, so the description carries full burden. It mentions 'monitor it for errors' which hints at a persistent/ongoing behavior, but doesn't clarify whether this tool blocks, spawns a background process, or what state it leaves the server in. It doesn't explain what 'monitoring' entails or whether it interacts with get_errors/clear_errors.

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?

One concise sentence conveying two actions (start and monitor). No waste. Could arguably split monitoring into more detail, but for length it's efficient.

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?

A dev-server lifecycle tool with no annotations and no output schema. The description doesn't explain return behavior, whether it blocks or returns immediately, how startup failures surface, or how monitoring relates to the sibling error/log tools. For a stateful lifecycle operation with several related siblings, more guidance is needed.

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% and there's only one parameter (cwd), which is self-explanatory ('Working directory for the app'). The description doesn't add meaning beyond the schema, but with a single, clearly-described required parameter, the schema does adequate heavy lifting. Baseline 3 is appropriate.

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 uses a specific verb (Start) plus the resource (Next.js dev server), with a clear secondary action (monitor it for errors). It clearly distinguishes from siblings like stop_dev_server and get_status. However, it doesn't fully capture the 'monitor' aspect's purpose or scope beyond a general mention.

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?

No guidance on when to use this tool vs alternatives like attach_to_dev_server or get_status. It doesn't say whether this is the tool to call at the start of a dev workflow or whether monitoring implies ongoing access. No exclusions or alternative references are provided.

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