# General Dispatch — for the agent

General Dispatch is the system of record for a local service business (HVAC first): contacts, jobs, appointments,
conversations, consent, and the runs that answer, book, remind and brief. You operate it through MCP tools. The
runtime executes; you propose.

## Connect

- **No key yet?** Connect to `https://api.generaldispatch.ai/mcp/start` (streamable HTTP, no authorization) and call `start_business`
  with the business's name and timezone (a website fills in the rest). You get the business's API key for the main
  endpoint and a claim link: give the link to the owner, who signs in with it to see the business and go live. Free;
  nothing reaches a real customer until the business is live.
- MCP endpoint (streamable HTTP): `https://api.generaldispatch.ai/mcp`
- Authorization: `Bearer <api_key>` — the key `POST https://api.generaldispatch.ai/signup` returned, or one the owner minted for you.
- Your key carries `execute` (and `administer` if the owner granted it). `approve` is never available to an agent:
  approvals, confirmations, parking and takeover are human decisions made on the owner page.
- If you are an MCP client that authenticates people rather than holding a key, use OAuth instead:
  `GET https://api.generaldispatch.ai/.well-known/oauth-protected-resource` names the authorization server, and
  `GET https://api.generaldispatch.ai/.well-known/oauth-authorization-server` describes it. Register (RFC 7591), send the owner to
  `/oauth/authorize` with PKCE (S256 is required), and exchange the code at `/oauth/token`. The token you get acts
  for the member who authorized it, with their scopes intersected against what they granted you — never `approve`.
  Tools your credential cannot call are not listed to it, so what you see is what you can do.

## First calls

1. `get_business` — who this is, timezone, hours, connected channels, counts.
2. Read `doc://policy` and `doc://brand` (MCP resources) before you act. `doc://pipeline` explains job stages.
3. For onboarding a new business, start from the `onboarding` prompt (it is also `skill://onboarding`).

## Rules the tools enforce

- Rich reads return a `ctx` token; every write that depends on what you read takes it back. Never edit or refresh a ctx.
- `send_message` returns `queued | needs_approval | denied`, never `sent`. Delivery happens later and is re-checked
  against consent, takeover and the versions in your ctx; a stale draft is denied at dispatch, which is correct.
- Consent is recorded by the ingest and by humans. You cannot grant it; a destination without consent denies.
- The owner's own number is `unknown` after signup. It becomes `granted` when the owner texts the business's main
  number once; until then owner notices and the morning brief are denied no_consent. Scheduled runs stay dark until a
  main phone number is connected and active.
- No price, urgency, discount or incentive language in any text we start. Identify the business. GSM-7 characters.
- One question per message. If a human has taken the thread, do nothing.

## Resources

- Skills: `skill://inbound-triage-and-booking`, `skill://estimate-followup`, `skill://morning-brief`, `skill://onboarding`
- Documents: `doc://policy`, `doc://brand`, `doc://pipeline`, `doc://templates`
- Health: `GET https://api.generaldispatch.ai/health`