# GiGa Admin Bearer MCP

Connect as an admin to create and manage gigs, set sessions and schedules, review applications, hire workers, and staff shifts.

- Admin docs: https://www.giga.jobs/docs/admin
- Worker OAuth MCP: https://www.giga.jobs/docs
- Production MCP endpoint: https://api.giga.jobs/mcp

## Connect as an admin

1. Add `https://api.giga.jobs/mcp` to your MCP client.
2. Choose the Admin Bearer MCP connection and provide the credential issued in GiGa Admin.
3. Start with a read, such as “List the latest draft gigs.”

```json
{
  "mcpServers": {
    "giga-admin": {
      "url": "https://api.giga.jobs/mcp",
      "headers": {
        "Authorization": "Bearer <from your MCP client secret manager>"
      }
    }
  }
}
```

Keep the Bearer credential in your MCP client’s secret manager. Never put it in a prompt, repository, screenshot, or log.

## What admins can do

- Create and update gigs.
- Add gig sessions, shifts, venues, roles, and staffing requirements.
- Open worker signup after review.
- Review applications and record hiring decisions.
- Assign or unassign workers and check staffing coverage.

## Create and publish a gig

1. Find the brand, program, role, and venue.
2. Call `gig_create` to create a draft.
3. Add shared occurrences with `gig_session_create`.
4. Add role-specific staffing requirements with `shift_create`.
5. Review with `gig_read` and `gig_links`.
6. After human review, call `gig_open_signup`.

## Hire and staff workers

1. List the gig’s applications with `application_list`.
2. Read the application with `application_read`.
3. Review the worker, role, and selected shifts.
4. After human confirmation, call `application_update` with the hiring decision.
5. Verify the result with `staffing_board_read`.

## Safety

Create drafts first. Confirm before publishing, hiring, rejecting, assigning, or unassigning. Read back the result before retrying a change.

# Admin tool reference

## Find setup resources

Resolve the brand, program, role, and venue IDs used when creating a gig and its shifts.

### `brand_list` — List brands

Find the brandId needed by program and gig creation.

- Access: **Read only**
- Example: `{ "limit": 50, "offset": 0 }`

### `program_list` — List programs

List programs with brand, gig, and role summaries.

- Access: **Read only**
- Example: `{ "brandId": 28, "includeStats": true }`

### `role_list` — List roles

List the staffing roles configured for a program.

- Access: **Read only**
- Example: `{ "programId": 9 }`

### `venue_list` — List venues

Find reusable venues by name or city before scheduling.

- Access: **Read only**
- Example: `{ "search": "Convention Center", "city": "Austin" }`

## Create & manage gigs

Create drafts, inspect and update gig content, manage artwork and links, then deliberately open applications.

### `gig_list` — List gigs

List gigs with optional lifecycle-status filtering and pagination.

- Access: **Read only**
- Example: `{ "status": "staffing", "limit": 20, "offset": 0 }`

### `gig_read` — Read a gig

Read a gig with its program, brand, schedule, and staffing details.

- Access: **Read only**
- Example: `{ "gigId": 184 }`

### `gig_create` — Create a draft gig

Create a program-scoped gig. Dates, roles, and staffing requirements belong on shifts.

- Access: **Writes production data**
- Example: `{ "title": "Summer product launch", "brandId": 28, "programId": 9, "city": "Austin", "state": "TX", "timezone": "America/Chicago" }`

### `gig_links` — Get gig links

Return canonical worker signup, admin review, edit, and graphics-preview URLs.

- Access: **Read only**
- Example: `{ "gigId": 184 }`

### `gig_update` — Update a gig

Update typed gig content and lifecycle fields. Status changes use guarded transitions and can notify workers.

- Access: **Notifies workers**
- Example: `{ "gigId": 184, "title": "Summer launch — Austin", "description": "Represent the brand at a live activation." }`

### `gig_asset_upload` — Upload gig artwork

Persist a logo or banner and attach it to the gig.

- Access: **Writes production data**
- Example: `{ "gigId": 184, "assetKind": "banner", "sourceUrl": "https://assets.example.com/launch-banner.jpg" }`

### `gig_open_signup` — Open worker signup

Transition a reviewed gig to staffing and return its public signup URL.

- Access: **Notifies workers**
- Example: `{ "gigId": 184 }`

## Sessions & shifts

Model each shared occurrence once, then add role-specific staffing requirements with shifts.

### `gig_session_list` — List gig sessions

List each shared training, event, setup, or other occurrence once.

- Access: **Read only**
- Example: `{ "gigId": 184 }`

### `gig_session_create` — Create a shared session

Create a dated occurrence whose details can be inherited by multiple role shifts.

- Access: **Writes production data**
- Example: `{ "gigId": 184, "sessionType": "event", "title": "Event day 1", "date": "2026-09-18", "startTime": "10:00", "endTime": "18:00", "venueId": 31 }`

### `gig_session_update` — Update a shared session

Update a shared occurrence; linked shifts inherit its schedule and venue changes.

- Access: **Writes production data**
- Example: `{ "gigId": 184, "sessionId": 72, "startTime": "09:30" }`

### `shift_list` — List shifts

List role-specific staffing requirements with role and venue data.

- Access: **Read only**
- Example: `{ "gigId": 184 }`

### `shift_read` — Read a shift

Read one shift with its gig, role, session, and venue details.

- Access: **Read only**
- Example: `{ "shiftId": 901 }`

### `shift_create` — Create a staffing shift

Create a role-specific headcount requirement, preferably attached to a shared session.

- Access: **Writes production data**
- Example: `{ "gigId": 184, "roleId": 4, "sessionId": 72, "requiredStaff": 8 }`

### `shift_update` — Update a shift

Update the role, schedule, headcount, venue, pay override, or notes for a shift.

- Access: **Writes production data**
- Example: `{ "shiftId": 901, "requiredStaff": 10 }`

## Applications & staffing

Review applications, make outcomes explicit, place workers into shifts, and verify the resulting staffing board.

### `application_list` — List applications

List a gig’s applications with worker, role, selected shifts, and contract state.

- Access: **Read only**
- Example: `{ "gigId": 184, "status": "applied", "limit": 50, "offset": 0 }`

### `application_read` — Read an application

Read one application with its worker, gig, selected shifts, and contract state.

- Access: **Read only**
- Example: `{ "applicantId": 512 }`

### `application_update` — Update an application

Set an application outcome, preferred role, apply mode, or selected shifts.

- Access: **Notifies workers**
- Example: `{ "applicantId": 512, "status": "hired", "primaryRoleId": 4 }`

### `staffing_board_read` — Read the staffing board

Read role boards, shifts, applicants, roster placement, and contract state.

- Access: **Read only**
- Example: `{ "gigId": 184 }`

### `staffing_assign_applicant` — Assign an applicant

Place an applicant into a shift, acknowledging active contract changes when required.

- Access: **Writes production data**
- Example: `{ "gigId": 184, "shiftId": 901, "applicantId": 512 }`

### `staffing_unassign_applicant` — Unassign an applicant

Remove an applicant from a shift, acknowledging active contract changes when required.

- Access: **Writes production data**
- Example: `{ "gigId": 184, "shiftId": 901, "applicantId": 512, "acknowledgeContractChange": true }`

### `gig_stats` — Read gig staffing stats

Read seats, staffing coverage, applications, and contract counts for a gig.

- Access: **Read only**
- Example: `{ "gigId": 184 }`