jira_list_users

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

The annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds context about routing through the connector authority and clarifies that 'effect' must be read, reinforcing the read-only nature. It also mentions approval_ref only for resuming writes, which is consistent with the read-only annotation. However, it does not describe side effects, error behavior, or pagination, so transparency is limited beyond the annotations.

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 concise and well-structured, starting with a clear purpose line, a routing note, and a bulleted list of arguments. It avoids unnecessary verbosity. The inclusion of internal details like 'Spring verifies it' is a minor distraction but not excessive. The format is easy to scan.

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 description is adequate for a simple read-only list operation but lacks details about the output format, pagination, or possible arguments within the 'arguments' JSON. Since an output schema is present (but not shown), some of this may be covered externally. However, the description alone does not fully inform the agent about what results to expect or how to pass filters. This is a moderate gap for a list operation.

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 description provides a one-line explanation for each parameter, which is essential given the schema has 0% coverage. For example, 'project_id' is described as 'Authenticated Project UUID' and 'idempotency_key' as 'Stable business-action identity'. Some descriptions are vague (e.g., 'Exact project correlation reference' is not self-explanatory), and the 'arguments' parameter is left as a generic JSON string without specifying valid contents. Overall, it adds meaningful semantics beyond the schema but with room for improvement.

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 immediately identifies the tool as a Jira connector operation for listing users, which conveys the core purpose. However, it does not explicitly say 'List users in Jira' as a complete sentence, relying on the operation name. The routing note about connector authority adds context but does not detract from clarity.

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 provides minimal guidance on when to use this tool versus alternatives. It mentions routing through a specific connector authority, but it does not compare against other list tools (e.g., slack_list_users) or explain scenarios where this tool is preferred. The requirement that 'effect' must be read is a usage constraint, but not a usage guideline. No clear when-to-use or when-not-to-use information is given.

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