Skip to main content
Glama

People who can open the project, with their names (spec D119) — whom to @mention or assign

list_people
Read-onlyIdempotent

People who can open the project, with their names (spec D119) — whom to @mention or assign.

Everyone who can open the project: its members (directly or through a team), the company's company admins, who open every project, and — when the project has company-wide access (D142) — every active seat of the company (via: company). Read-only, any member and AI agents. Use it to turn the user ids in an issue (reporter, assignee, created_by, …) into names, and to find the id of a person to @mention ([@Name](mention:usr_…)) or assign. People whose account was deleted or whose seat was deactivated are left out. Sorted by name. Adding or removing members is web only. Agent accounts (D144): on Premium companies the company's agents whose owner can open the project are listed too (kind: agent, user_id = agt_…, role = the owner's role here, owner_id, owner_name, handle, status) — assign them or @mention them as [@Name](mention:agt_…); the owner is told. Paused / stopped agents are listed with their status (pickers grey them out); deleted agents are left out. Agents never take a seat.

One call per project is enough: keep the list for the rest of the task. Use it to name the reporter or assignee of an issue (match user_id), and to @mention someone in add_comment / update_comment as [@Name](mention:usr_…) with the exact user_id and name from here — never invent an id. When several people share a name, ask the user which one. An item with via: "company" is in only through company-wide access (get_project company_access). Someone missing from the list cannot open the project and would not be notified.

Input Schema

NameRequiredDescriptionDefault
project_keyYesProject key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, but the description adds substantial context beyond them: inclusion rules for members/admins/company-wide seats, exclusion of deleted/deactivated people, agent-account behavior, paused/stopped status, sorting, and notification implications. No annotation contradiction is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and audience, which is good, but it is very long for a one-parameter read tool and repeats usage details around naming, mentions, and exact ids. Much of the detail is useful, but several sentences could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 burden of explaining the returned population and important fields such as user_id, name, via: company, and agent fields. It also explains exclusions and sorting, making the definition complete enough for an agent to use the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has full description coverage for the single project_key parameter, so the description does not need to explain its format or pattern. It reinforces project scoping with 'one call per project' and project-wide access context, but adds little direct parameter semantics beyond the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: listing people who can open a project, including members, company admins, and company-wide access users. It clearly distinguishes the result from related tools like list_watchers by defining the access set and its use for mentions and assignments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage contexts: resolving issue user ids to names, finding ids for @mentions or assignments, and using exact ids from this result. It also states alternatives and constraints: adding/removing members is web only, one call per project is enough, ask the user when names collide, and missing people cannot open the project.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources