import type { ToolDefinition } from "./types.js";
/**
 * `GET /api/v1/repositories/:repository_id/members` as a tool — shipped in the
 * platform (`specguard/config/routes.rb`, `Api::V1::UserRepositoryMembersController#index`,
 * SPGD-875).
 *
 * == Memberships only, never `keys_minted`
 *
 * The endpoint answers five fields per row — `id`, `handle`, `permissions`,
 * `granted_by`, `created_at`, ordered by handle — and deliberately NOTHING
 * else. Four of the five are the rows the web members page renders
 * (`handle`, `permissions`, `granted_by`, `created_at`, under the same
 * names); `id` is served to the API caller alone — that page has no id
 * column, the id appears there only inside edit and revoke links.
 * `keys_minted` is a `keys.manage` disclosure
 * that page gates separately; this read answers memberships to a
 * `members.manage` holder and no more. A tool that promised counts here would
 * be promising something the endpoint refuses to say.
 *
 * == The membership `id` is served
 *
 * Each row's `id` is the MEMBERSHIP id — the very identifier
 * `update_repository_member_permissions` and `remove_repository_member` name.
 * The id is not portable: lookup is scoped through the repository, so a
 * foreign id is refused 404 server-side, and there is no name-based lookup.
 *
 * == No client-side capability probing
 *
 * The server gates at `current_repository(:members_manage)`: a non-member gets
 * 404 (the repository's existence stays hidden), a member without the
 * capability gets 403 with SpecGuard's own sentence. This tool predicts
 * neither; it reports what came back.
 */
declare const listRepositoryMembers: ToolDefinition;
export default listRepositoryMembers;