jenkins_enable_node

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. The description implies this is a state-changing operation (bringing a node online), but doesn't disclose what happens to a node that's already online (idempotency), what state transitions occur, whether authorization/permissions are needed, or the effect of the session_name parameter. Minimal disclosure for a mutation 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 compact — a one-line purpose statement plus two terse parameter lines. It's appropriately sized with minimal waste, though the parameter restatements add little value.

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?

For a 2-parameter state-changing mutation tool with no annotations, the description is thin. It doesn't describe return/output behavior despite an output schema existing, doesn't contrast with sibling jenkins_disable_node or address idempotency, and doesn't note node prerequisites. A boolean success/failure output likely exists but isn't characterized.

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?

With 0% schema description coverage, the description must compensate, but it only restates the parameter names ('Node name to enable', 'Jenkins session to use') without adding format, validation, or behavioral detail. session_name is arguably clarified by its default value in the schema, but the description adds no meaning beyond a literal restatement of the names.

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 verb (bring back online) and resource (Jenkins node/agent), making the purpose unambiguous. It distinguishes from sibling jenkins_disable_node (the opposite operation) without explicitly naming it, though the inverse action is directly referenced by the phrase 'back online'.

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 is given on WHEN to use this tool vs alternatives. While the counter-operation is jenkins_disable_node, the description doesn't mention it, nor does it note prerequisites (e.g., node must be in an offline/disconnected state to enable, or that a disconnected node vs a disabled node are different states). The sibling jenkins_get_node_info could check node state, but this isn't suggested.

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