List Micro project members

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about the returned content—owner, delegated members, roles, promotion authority—and that it applies to the linked project, but it does not discuss permissions, limits, or other behavioral nuances. The annotation coverage lowers the burden, so a average score is appropriate.

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 a single, focused sentence that front-loads the resource and immediately specifies the data categories returned. There is no fluff or repetition of schema details.

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 read-only tool with one optional parameter, full schema coverage, an output schema, and complete safety annotations, the description conveys the essential information an agent needs. The only slight gap is that 'linked project' is left implicit, but the tool's purpose and behavior are still sufficiently clear.

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 only parameter, 'path', is fully documented in the schema with 100% coverage, so the description does not need to restate its meaning. It also does not add extra semantics beyond the schema, such as how 'linked project' relates to the path, so the schema-based baseline of 3 is correct.

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 uses a specific verb ('List') and names the exact resource and data returned: 'linked project's owner and delegated members, roles, and promotion authority'. This clearly distinguishes it from membership mutation or invitation sibling tools.

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 intended use case—listing project membership—is implied by the verb and object, but the description never explicitly says when to prefer this over siblings like micro_member_set or micro_ember_remove. No exclusions or alternative tool hints are provided, so guidance is only implicit.

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