Retrieve all available roles from Targetprocess and check whether each role can carry effort. Use this to identify valid role assignments for work items.
List roles (Developer, Product Owner, ...). hasEffort tells whether a role can carry effort.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is fully covered without the description's help. The description adds the hasEffort field semantics, which is useful since there is no output schema, but it discloses no traits like ordering, pagination, or whether custom roles are included (the '...' only loosely aligns with openWorldHint). No contradiction with 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?
Two short sentences front-loaded with the action and resource, followed by a targeted clarification of a non-obvious field. The role examples and hasEffort explanation each earn their place; there is zero redundancy or filler.
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 0-param, read-only list tool, the essential facts are present: what is returned and what the key field means. The hasEffort explanation partially compensates for the absent output schema, though other role attributes are left unspecified. The description is adequately complete for the tool's simplicity.
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 tool takes zero parameters, so the schema has nothing to document and the description carries no parameter burden — this matches the baseline of 4 for 0-param tools. The hasEffort explanation aids output comprehension rather than parameter semantics, which is a reasonable bonus given the missing output schema.
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 gives a specific verb+resource ('List roles') and concrete examples ('Developer, Product Owner, ...') that make the domain recognizable. Introducing the hasEffort field clarifies what the result set is about even before calling. It doesn't explicitly differentiate from sibling tools, but the resource 'roles' is unique among the read_* siblings, so confusion risk is low.
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 hasEffort explanation implies a usage scenario — determining which roles can carry effort — which is indirect usage context. However, there is no explicit when-to-use, when-not-to-use, or routing to related siblings such as read_people or write_set_role_effort. The agent must infer the appropriate call context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.