jenkins_list_views

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It doesn't mention whether a live session is required, whether it reads from a local cache, how many views might return, pagination, or error behavior. The description is a pure read operation but gives no safety/reliability context.

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 (three lines including the Args section) and front-loaded with the actionable sentence 'List all Jenkins views.' Efficient and to the point, though the Args re-statement is arguably redundant with the schema.

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?

This is a simple listing tool with one parameter, so minimal description may suffice. An output schema exists (no specifics needed on return format), and the parameter is trivially documented. However, given zero annotations and the broader Jenkins tool family, a note about session requirements or the difference from jenkins_get_view would strengthen completeness.

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?

The schema covers the single parameter (session_name) at 100% with a default. The description says 'Jenkins session to use,' adding mild meaning beyond the schema's title 'Session Name.' With only one param and full schema coverage, the baseline of 3 is appropriate; the brief description adds minimal but non-zero value.

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+resource ('List all Jenkins views') that clearly states what the tool does. It doesn't explicitly distinguish from siblings, but 'list_views' vs 'get_view' and 'create_view'/'delete_view' makes the purpose reasonably clear from context.

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 jenkins_get_view or jenkins_list_jobs. There is no mention of exclusions, prerequisites (e.g., must be connected first via jenkins_connect), or preferred use cases. While the sibling naming provides some context, the description itself offers no usage direction.

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