# Zauber People

Zauber People is Zauber's private, versioned HR management system.

Public integration information:
- Human entry: https://people.gozauber.com/
- Agent guide: https://people.gozauber.com/agents
- MCP server: https://people.gozauber.com/mcp
- OAuth protected-resource metadata: https://people.gozauber.com/.well-known/oauth-protected-resource/mcp
- OAuth authorization-server metadata: https://people.gozauber.com/.well-known/oauth-authorization-server/api/auth
- Protected OAuth client registration: https://people.gozauber.com/api/auth/oauth2/register
- Human enrollment page: https://people.gozauber.com/settings/agents
- REST base path: https://people.gozauber.com/api/v1

Authentication and authorization:
- Humans authenticate with a verified @gozauber.com Google Workspace account.
- MCP clients use OAuth 2.1 authorization code flow with PKCE.
- Unknown agents cannot register anonymously. Ask the human to open https://people.gozauber.com/settings/agents, create a five-minute one-time enrollment code, and paste it into the agent.
- Send that code only to the registration endpoint as Authorization: Bearer <enrollment-code>. It registers one public PKCE client and grants no HRMS data access.
- Once a valid enrollment code passes the registration capacity gate, it is consumed before OAuth metadata validation. A metadata-rejected attempt needs a new code.
- Missing, expired, or reused enrollment codes return invalid_token with instructions at https://people.gozauber.com/agents#enrollment.
- MCP access tokens expire after 15 minutes and are bound to the exact MCP resource audience.
- Persistent clients must register both authorization_code and refresh_token grants, then request the hrms:read and offline_access scopes.
- offline_access is never granted by default. It requires explicit teammate consent and returns a rotating refresh token.
- A client should refresh only when its access token is near expiry or rejected, and must replace the stored refresh token after every successful refresh.
- An authenticated identity must match an active HRMS person record.
- Every MCP tool and REST operation invokes the same application authorization policies.
- A tool name or endpoint never grants permission by itself.
- Protected registration accepts hrms:write directly, and newly enrolled clients have it in their requestable scope ceiling. That client capability does not grant write access.
- The authorization-code flow must explicitly request hrms:write and the teammate must approve it. Refreshing an existing read-only grant never adds hrms:write.
- An authorization request that omits scope falls back to openid profile email hrms:read, never offline_access or hrms:write.
- Do not call the authenticated OAuth client-administration endpoint with an MCP bearer; it is not part of the write-scope flow.
- With hrms:write, MCP exposes the same versioned HRMS create, update, and restore capabilities as the UI.
- Write tools retain human-role checks, optimistic concurrency, append-only revisions, and human-plus-agent attribution.

Available with hrms:read:
- hrms_system_info
- hrms_people_list
- hrms_people_export_xlsx
- hrms_onboarding_requests_list
- hrms_person_get
- hrms_engagements_list
- hrms_engagement_get
- hrms_person_history
- hrms_person_version_get
- hrms_record_history
- hrms_leave_requests_list
- hrms_documents_list
- hrms_compensation_list
- hrms_equity_programs_list
- hrms_equity_grants_list

Additionally available with hrms:write:
- hrms_person_create, hrms_person_update, hrms_person_restore
- hrms_person_onboarding_code_create, hrms_onboarding_request_link, hrms_onboarding_request_person_create
- hrms_engagement_create, hrms_engagement_update
- hrms_leave_request_create, hrms_leave_request_update
- hrms_document_create, hrms_document_update
- hrms_compensation_create, hrms_compensation_update
- hrms_equity_program_create, hrms_equity_program_update
- hrms_equity_grant_create, hrms_equity_grant_update

Zauber People is AI-first: UI and MCP business capabilities stay in parity and use the same application services.