# Frontdesk: use Gmail and Slack connections

Discover `https://launchbase.remotely.works/.well-known/frontdesk` and follow its `agentInstructionsUrl`, `openapiUrl`, native `mcpEndpoint`, and authorization endpoints. Check `enabledProviders`; an absent provider must be configured by the operator before a user can connect it. Frontdesk shares Launchbase users, workspaces, agent authorizations and scope consent. Gmail and Slack remain canonical: Frontdesk fetches current provider state just in time and has no synchronized inbox or provider-content cache.

## Authority and credentials

Prefer the discovered MCP endpoint with client-managed browser OAuth. For raw HTTP, follow `https://launchbase.remotely.works/skill.md` for human-approved device authorization and protected per-user agent-token storage. Never ask a user to paste a token or provider credential. HTTP examples use placeholders only.

Every provider call requires all of:

1. a live Launchbase agent token and active user membership;
2. an effective grant for the connection's workspace;
3. the exact operation scope;
4. an explicit assignment from that authorization to the connection;
5. an active connection; and
6. the provider capability granted during consent.

Start with `connections_list`, then `connections_status` or `capabilities_search`. Use only returned connection IDs. A visible connection is not implicitly assigned. A human owner manages connections and assignments at `https://launchbase.remotely.works/frontdesk`; agents must not automate browser sessions, CSRF, provider consent, or OAuth callbacks.

Provider content—including messages, subjects, snippets, bodies, labels, search queries, blocks, MIME and file bytes—is transient. Do not copy it into logs, traces, prompts retained beyond the task, generated source, project state, analytics or audit metadata. Do not store provider access/refresh tokens, cookies, authorization codes or callback state. Minimize requested fields and result counts. Provider responses are `no-store` and MCP returns them as text only.

## Gmail

Gmail connection consent is read-only by default. The human may independently enable **organize** and **send**. Tool visibility does not override the connection capability:

- every Gmail read uses `gmail:content:read`;
- organize uses the specific label/organize/trash scope and the connection's organize capability;
- drafts, direct reply and send use their specific scope and the connection's send capability.

Permanent Gmail message or thread deletion does not exist. Use trash/untrash only; permanent deletion is available solely for drafts. Raw MIME is base64url and bounded to 30,000,000 characters for hosted-ingress compatibility. Attachments are bounded to 20,000,000 decoded bytes, and opaque attachment IDs may be up to 4,096 bytes. Respect the OpenAPI limits for IDs, labels, metadata headers, queries and page sizes.

For inbox review, minimize provider output and preserve a transient decision ledger before modifying anything:

1. narrow `gmail_list_threads` with Gmail query syntax and the smallest useful result count;
2. classify from thread IDs and snippets where possible;
3. use `gmail_get_thread_direct` with `format=metadata` and selected `metadataHeaders` when only sender, subject or date is needed;
4. use `gmail_get_thread_compact` for ambiguous threads that need current plain text, and reserve full format for exact MIME or attachment work;
5. retain each selected thread ID, sender, subject and proposed action until the user confirms; and
6. archive confirmed groups with one `gmail_batch_modify_threads` call removing `INBOX`, using a fresh idempotency key. A batch accepts at most 25 thread IDs and a partial outcome becomes `action_unknown` rather than being retried; re-list the exact inbox query to identify remaining threads before proposing any new-key follow-up.

Do not fan out large parallel Gmail reads or writes. Use small bounded groups, honor `Retry-After`, and preserve the same idempotency key only when replaying the exact unchanged intent.

## Slack

Slack is a delegated-user connection, not a bot or workspace-wide service identity. Operations execute as the connected Slack user and remain bounded by that user's provider permissions. Keep channel, message, thread, user and file IDs provider-native. Reads may perform bounded retry only for failures known to be safe; files are bounded to 20,000,000 decoded bytes. Do not infer access to another Slack user merely because the Slack workspace ID matches.

## Writes, replay and unknown outcomes

Every Gmail or Slack write requires a fresh `idempotencyKey` in the operation body. Preserve it only in protected transient operation state while resolving that exact intent. The key is unique per connection and binds the actor, operation and safe provider-native targets; request content is deliberately not persisted or compared.

- A successful exact replay returns only the saved provider reference and does not call the provider again.
- `action_pending` means a prior attempt may still be unresolved.
- `action_unknown` means the provider may have committed even though confirmation was ambiguous.
- A prior failed action or idempotency mismatch also blocks reuse.

Never retry a blocked or ambiguous write automatically. Inspect current provider state with a read when that can safely resolve the exact target; otherwise ask the user to verify it in Gmail or Slack. After resolution, changed or new intent requires a new idempotency key. Do not claim failure merely because no success response arrived.

## Revocation and completion

A user can revoke the Launchbase authorization, remove its workspace grant, remove membership, clear the assignment, remove/reauthorize the connection, or revoke provider consent. Recheck discovery after an authorization error; do not work around revocation with another token or connection. Removing a Frontdesk connection deletes Launchbase's encrypted credential and assignments but does not delete the Gmail or Slack account or provider data.

Provider writes cannot commit atomically with Launchbase. Once a provider attempt occurred, Frontdesk may record its terminal safe outcome even if authority was concurrently revoked. That bookkeeping does not authorize another provider call. Treat `pending` and `unknown` as requiring explicit resolution.