taiga_users_list

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

With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states that it lists users and can filter by project, but it doesn't mention that it's a read-only operation, whether authentication is required, if pagination is involved, or what specific data is returned. These are significant gaps for a tool with no structured metadata.

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 consists of two short sentences that are direct and free of fluff. 'List users' is front-loaded as the primary action, and 'Filter by project' adds essential scoping without redundancy. Every word serves a purpose, making it highly concise and well-structured.

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 tool with a single optional parameter and no output schema, the description is minimally adequate. It conveys the core function and the filter option. However, it lacks context about the return format, pagination, authentication requirements, or whether the list represents all users or only those visible to the authenticated user. This leaves the agent with unanswered questions about the tool's behavior in real usage.

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 fully documents the single 'project' parameter with a description of 'Project ID', covering 100% of parameters. The description's 'Filter by project' reinforces this but adds no extra detail (e.g., whether the filter is optional or required, or the effect of omitting it). Since the schema covers the parameter adequately, the baseline score of 3 is appropriate.

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 'List users' which identifies the action and resource, fulfilling the purpose requirement. The addition of 'Filter by project' indicates a scoping capability. However, it doesn't explicitly distinguish this from related tools like taiga_users_get or taiga_users_me, though 'list' implies a collection operation.

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 provided on when to use this tool versus alternatives such as taiga_users_get, taiga_users_me, or taiga_memberships_list. The description doesn't mention any prerequisites, exclusions, or explicit use cases beyond the inherent purpose, leaving the agent to infer appropriate usage from the name alone.

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