/seat-inventory

name: "Anthropic Admin Seat Inventory"
description: >
  Seat and access inventory for a client's Anthropic organization:
  members and their organization roles, pending and expired invites,
  workspaces and per-workspace membership, and how to turn them into a
  seat count, an admin-role review, and an offboarding check against the
  client's leaver list. All tools are read-tier.
when_to_use: >-
  When counting a client's Anthropic or Claude Console seats, reviewing who holds admin
  roles, checking pending invites, or confirming a leaver no longer has access.
  Use when: anthropic seats, claude console users, anthropic org members, who has
  anthropic access, anthropic invites, anthropic workspace members, anthropic offboarding
  check, or anthropic admin roles.

Anthropic Seat Inventory

Overview

An MSP that supplies or manages Claude for a client needs to answer three questions on a schedule: how many seats are in use, who holds the powerful roles, and whether people who left still have access. This skill answers them from the Admin API. It reads only; removing a user or revoking an invite is done by a client admin in Claude Console.

Anti-triggers

• **API keys a leaver created** — keys outlive their creator's seat; use

[key-and-audit-review](../key-and-audit-review/SKILL.md) (admin-gated).

• **Who is actually using Claude Code** — membership is not usage; use

[claude-code-adoption](../claude-code-adoption/SKILL.md).

Key Concepts

• **Organization role** (`role` on a user). Console and API orgs use

`user`, `developer`, `billing`, `admin`, and `claude_code_user`. Claude Enterprise orgs use `user`, `owner`, `primary_owner`, `membership_admin`, and `managed`. Filter with the `roles` argument.

• **Invites** have a status of `pending`, `accepted`, or `expired`. A

pending invite is a seat about to be taken; an old pending invite to a departed person is still a way in once accepted.

• **Workspaces** split keys, usage, and limits. A user can belong to the

org but to only some workspaces, each with its own workspace role. The default workspace is hidden unless you pass `include_default: true`; archived workspaces need `include_archived: true`.

Workflows

Seat count

1. `anthropic_admin_organization_get` - confirm the org. 2. `anthropic_admin_users_list` with `limit: 1000`, paging `after_id` until `has_more` is false. 3. Group by `role` and count. Report the total, the count per role, and the newest `added_at` dates (recent additions explain a jump since the last review). 4. `anthropic_admin_invites_list` with `statuses: ["pending"]` - pending seats, listed separately from active ones.

Admin-role review

1. `anthropic_admin_users_list` with `roles: ["admin"]` (Console org) or `roles: ["owner", "primary_owner", "membership_admin"]` (Enterprise). 2. Compare against the people the client says should administer the org. Flag anyone extra, and flag personal email domains on admin seats. 3. For workspace-level admin, `anthropic_admin_workspaces_list`, then `anthropic_admin_workspace_members_list` per workspace, and look at the workspace role on each membership.

Offboarding check

Given a leaver's email address:

1. `anthropic_admin_users_list` with `email` - still a member? 2. `anthropic_admin_invites_list` with `email` - any invite still pending? 3. If a user ID came back, `anthropic_admin_workspace_member_get` for each workspace, or note the org membership alone if they have no workspaces. 4. Report "still has access: yes/no" with the evidence, and hand the removal to the client admin. If the caller has the admin tier, continue with the leaver's API keys in [key-and-audit-review](../key-and-audit-review/SKILL.md).

A person missing from `anthropic_admin_users_list` has no Console seat in this org, but may still be a member of a different Anthropic org the client owns. Say which org you checked.

Gotchas

• `anthropic_admin_users_list` filters by exact email. Aliases and plus

addresses do not match; when the client's identity provider uses aliases, list everyone and match yourself.

• Counting seats from one page undercounts silently. Page to the end.
• Workspace membership is per workspace. There is no single call for "all

workspaces this user is in"; loop the workspaces.

• Invite and user records hold names and email addresses. Keep reports

that leave the MSP to counts and roles unless the client asked for names.

Related Skills

• [api-patterns](../api-patterns/SKILL.md) - pagination, tiers, errors
• [key-and-audit-review](../key-and-audit-review/SKILL.md) - keys a member created, and role-change history