get_project_context returns memberCount but no member list, so assignees cannot be resolved — possibly a missing credential or scope on the MCP connector

create_ticket's assigneeId parameter is documented with the instruction "Call get_project_context first to list assignable members." get_project_context does not return any member list. Its response includes a _count object with ProjectMember set to 2 and a memberCount field set to 2, but no array of members, no user IDs, and no names. There is no other tool in the surface that enumerates users. The consequence is that assigneeId can never be populated from information the connector itself exposes. The tool description points at a capability that the response payload does not carry, so an assistant following the documented flow reaches a dead end and has to ask the user to supply an opaque user ID by hand. The create_ticket description also warns that an unassigned ticket is one nobody picks up, so the gap pushes callers toward exactly the outcome the tool is trying to prevent. The reporter's suspicion, worth checking first: this may not be a payload bug but a credentials or scope problem in how the MCP connector is provisioned. When the connector is created and added to Codmir, it may not be passing the full set of credentials — an API token or CLI token with a broader scope — that member data requires. If member listing is gated behind a scope the connector never requests, the server would correctly omit the member array while still reporting the count, which matches the observed response exactly. Please confirm which of the two it is before treating this as a response-shape fix. Note this is distinct from, though adjacent to, the missing project enumeration filed separately: that one is about discovering projects, this one about discovering people within a project.