Inspect Next.js runtime

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

Annotations already signal destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the description does not need to restate the safety profile. It adds that the tool compiles routes or resolves Server Actions through a local dev server, which implies execution/behavioral effects. However, it does not explain what destructive side effects may occur, such as running server code with external impact.

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 one concise sentence with no filler. It front-loads the two concrete operations and scopes them to the selected local Next.js dev server. Every word contributes useful meaning.

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?

The output schema and annotations supply some context, but the description is thin for a tool with two distinct operation modes and a destructive/open-world profile. It does not mention the need for an active session or that resolving a Server Action can execute arbitrary server-side code, leaving the agent to infer important preconditions.

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%, and the description only partially compensates. It explains the two inspection modes—compiling a route or resolving a Server Action—but never clarifies that sessionId identifies the selected dev server/session or how path/actionId map to the mode. The schema provides const values and required fields, but the description adds little beyond a high-level paraphrase.

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 and resource: 'Compile one Next.js route or resolve one Server Action through the selected local Next development server.' This clearly identifies what the tool does and distinguishes it from sibling browser/debug tools by focusing on Next.js runtime operations. It does not explicitly name sibling alternatives, so it stops short of a 5.

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?

There is no guidance about when to use this tool instead of siblings like web_debug_evaluate or web_breakpoint_set. The phrase 'through the selected local Next development server' implies a session/context is required, but it does not state prerequisites, exclusions, or alternative conditions.

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