tc_list_project_members

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: it defines the output shape, the meaning of status values, the default for include_removed, and notes that member ids are what folder-permission tools expect. 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?

The description is front-loaded with a one-sentence summary, then organizes parameter explanations and return format in clear Args/Returns sections. Every sentence adds needed information without padding.

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 list tool with an output schema present, the description covers all necessary context: parameters, defaults, output shape, and cross-tool compatibility. Given the sibling set, this is a complete and self-contained description.

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 descriptions are 0% covered, so the description must fully explain parameters. It does: project_id is sourced from tc_list_projects, include_removed controls whether REMOVED users appear and defaults to False, and group_id filters to a specific group. This adds meaning entirely beyond the raw 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 opens with a specific verb and resource: 'List members (users) of a project with their role and status.' This clearly differentiates it from sibling tools like tc_list_group_users and tc_list_project_roles by specifying the subject is project members and includes role/status.

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 clear usage context: project_id comes from tc_list_projects, group_id is optional and references tc_list_groups, and include_removed changes the result set. It does not explicitly state when not to use this tool, but the provenance and filtering guidance make the intended use clear.

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