get-project-member-group-list

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds behavior the annotations cannot: default page size 20, max 100, the totalCount > size paging trigger, and a warning that the response is compact (id and code only) — that last point is genuinely useful because it signals a truncated payload.

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 purpose is front-loaded in the first sentence and the blocks are scannable, but the member-groups explanation and the closing usage sentence restate each other, and the two examples add little for a 3-parameter tool.

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?

With no output schema, the description carries the return-value burden and does so by listing id and code plus totalCount. Pagination, URL parsing and intended use are all covered; only error/no-results behavior is left unstated.

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?

Schema coverage is 100%, so baseline is 3, but the description earns extra by explaining how to obtain the projectId from a URL and by pairing pagination parameters with worked examples. It adds extraction and default-value context beyond the schema text.

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?

States a specific verb and resource ('Get list of member groups in a project') and defines what a member group is, which implicitly separates it from get-project-member-list and get-member. It never names those siblings directly, so the differentiation is inferred rather than explicit.

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 closing line gives a concrete use case ('to find member groups for assigning tasks to groups of members'), and the URL Pattern Recognition block tells the agent how to derive projectId from a Dooray task URL. No explicit when-not-to-use or named alternatives, so short of a 5.

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