Attach to inspector

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

Annotations already mark this as destructive, but the description adds useful behavioral detail: it can enable the inspector via pid, runs the target as the MCP user, enforces loopback, and returns a sessionId. This goes beyond the annotation flags and helps the agent understand the side effects and safety boundary.

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 compact and front-loads the essential action and return value. Each sentence contributes: attachment mode, side-effect caveat, tool distinction, and security constraint. The mention of evaluate is somewhat adjacent to debug_attach but still helps clarify the tool's boundary.

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 five optional parameters, 100% schema coverage, no output schema, and no required fields, the description covers the key operational details: what it returns, how to specify a target, loopback enforcement, and the trust requirement. It could state the selection precedence among wsUrl, host+port, and pid more explicitly, but it is largely 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 100%, so the parameters are already well documented. The description adds some grouping value by naming the three attachment modes (wsUrl, host+port, pid), but it does not need to repeat schema details. This is a solid baseline-3 score for parameter semantics.

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 action ('Attach to an existing Node inspector'), the target resource, the loopback scope, and the return value ('return a new sessionId'). It also references sibling tools like launch and evaluate in a way that distinguishes this attachment action from process launch and JS evaluation.

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 clearly frames when this tool applies: when there is an existing Node inspector to attach to, and it lists the accepted attachment routes. It contrasts with launch and evaluate, which helps route to siblings, though it does not explicitly say 'use debug_launch when you need to start a new process' as a direct exclusion.

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