> ## Documentation Index
> Fetch the complete documentation index at: https://developer.meetergo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# meetergo MCP Server

> Let an AI agent run your scheduling: check availability, book and reschedule meetings, manage contacts, and set up an entire account from a website

The meetergo MCP server gives an AI agent real access to a meetergo account. It can check availability, book, reschedule and cancel meetings, manage contacts and routing forms, and set up the Mira website assistant end to end from nothing but a website address.

<Info>
  Available on **every plan, including Free**. All you need is a Personal Access Token from [Integrations → API](https://my.meetergo.com/integrations).
</Info>

<Warning>
  This is not the documentation search server. `developer.meetergo.com/mcp` searches these docs and cannot change anything. The server described here books meetings and writes to a real account. See [Documentation MCP Server](/developer-docs/mcp-server) for the other one.
</Warning>

## Connect

<CodeGroup>
  ```bash Claude Code theme={null}
  claude mcp add meetergo --transport http https://mcp.meetergo.com/mcp \
    --header "Authorization: Bearer rgo-YOUR_TOKEN"
  ```

  ```json Local (npx) theme={null}
  {
    "mcpServers": {
      "meetergo": {
        "command": "npx",
        "args": ["-y", "@meetergo/mcp-server"],
        "env": { "MEETERGO_TOKEN": "rgo-your_token_here" }
      }
    }
  }
  ```

  ```bash Verify the endpoint theme={null}
  curl -s https://mcp.meetergo.com/healthz
  # {"ok":true,"version":"0.6.3",...}
  ```
</CodeGroup>

The hosted endpoint is:

```
https://mcp.meetergo.com/mcp
```

The `/mcp` path is part of the endpoint. `mcp.meetergo.com` on its own is not it.

**Claude Desktop** users can skip configuration entirely: download `meetergo.mcpb` from the [latest release](https://github.com/meetergo/meetergo-mcp-server/releases/latest) and open it. The token is collected in the install dialog and stored as a sensitive value.

## Authentication

<AccordionGroup>
  <Accordion title="Personal Access Token">
    The simplest route, and the one that works everywhere. A PAT starts with `rgo-` and always acts as its owner — it cannot impersonate another user.

    Send it as a bearer credential:

    ```
    Authorization: Bearer rgo-...
    ```

    Scope it when you create it. The capability groups (scheduling, CRM, Mira, forms, account) let you give an agent only what it needs.
  </Accordion>

  <Accordion title="OAuth">
    The hosted endpoint publishes RFC 9728 protected-resource metadata, so an OAuth-capable client discovers the flow on its own:

    ```
    https://mcp.meetergo.com/.well-known/oauth-protected-resource
    ```

    Clients are **pre-registered**. `mcp-claude` is the public client and uses PKCE with no secret, so it is safe to configure directly.

    Dynamic client registration is deliberately not enabled: it is superseded by Client ID Metadata Documents in the authorization spec, and a directory client that registers on every connection would fill the realm with throwaway records.
  </Accordion>

  <Accordion title="Platform API Key">
    A Platform API Key (`ak_live:<uuid>:<secret>`) names no user of its own, so it must say who it is acting as:

    ```
    Authorization: Bearer ak_live:...
    x-meetergo-api-user-id: <user-uuid>
    ```

    The server fails at startup if one is supplied without the other, rather than answering the first call and then breaking on the second.
  </Accordion>
</AccordionGroup>

## Set up an entire account with one prompt

The server ships two guided flows as MCP prompts. Clients with prompt support surface them natively as `meetergo: onboard` and `meetergo: weekly-review`.

<Steps>
  <Step title="Orient">
    `get_setup_status` returns the launch checklist as the dashboard computes it, so the agent never rebuilds what already exists.
  </Step>

  <Step title="Analyse">
    `propose_conversion_setup` reads a sample of the website and proposes a persona, grounded instructions, qualification questions and the site's own legal links. Nothing is stored.
  </Step>

  <Step title="Approval gate">
    The agent presents the proposal and **stops**. Nothing is written before the user explicitly approves.
  </Step>

  <Step title="Build">
    Meeting types, the knowledge base crawl, a real routing form for qualification, and the assistant configuration — with the website chat still switched off.
  </Step>

  <Step title="Prove">
    `run_test_drive` sends scripted visitors through the customer's own assistant (a buyer who books, a lead who wants a callback, an adversary probing for invented promises) and returns pass/fail verdicts with full transcripts. Preview mode: no bookings are created and no email goes out.
  </Step>

  <Step title="Install and go live">
    The embed snippet, then `verify_widget_install` to confirm the loader and the account's own key are actually on the page, and only then the switch to live.
  </Step>
</Steps>

## What the tools cover

<CardGroup cols={2}>
  <Card title="Scheduling" icon="calendar">
    Availability, book, reschedule, cancel, list appointments, add guests, update notes
  </Card>

  <Card title="Meeting types" icon="clock">
    Create and edit, one-time booking links, booking page and personal page settings
  </Card>

  <Card title="Contacts" icon="user">
    Create, update, search, bulk import, tags and account owners
  </Card>

  <Card title="Website assistant" icon="robot">
    Crawl a site into the knowledge base, write instructions, build qualification forms, test drive, verify install
  </Card>

  <Card title="Routing forms" icon="arrows-split-up-and-left">
    Create, update and send forms; qualifiers and fallback rules
  </Card>

  <Card title="Webhooks" icon="webhook">
    Register, update and remove endpoints
  </Card>
</CardGroup>

Every tool carries MCP annotations (`readOnlyHint`, `destructiveHint`), so a host can confirm with the user before anything irreversible happens. Those annotations are honest: `run_test_drive` is marked as a write because it persists its verdict and spends model budget, and `reschedule_appointment`, `update_appointment_notes` and `update_contact` are marked destructive because each one replaces something a person would miss.

## Plan limits are answers, not walls

When an account's allowance runs out, tools return the limit structurally — which feature, what the next tier unlocks, and the upgrade link — instead of an opaque error. `get_me` reports the tier and caps up front so an agent can warn before starting something the plan cannot finish.

The connection itself is never gated by plan, and the tool descriptions instruct the agent not to raise upgrades unless a requested action is actually blocked.

## Security model

<AccordionGroup>
  <Accordion title="Tokens act as their owner, and can be scoped">
    A Personal Access Token cannot impersonate another user; the API rejects the impersonation header outright. Capability groups let you hand an agent the least it needs.
  </Accordion>

  <Accordion title="No token passthrough">
    The hosted server never forwards a credential handed to it by an OAuth client. An access token is validated against our Keycloak realm — issuer, audience, signature, expiry — and exchanged for a separate token before any API call, as the MCP authorization spec requires.
  </Accordion>

  <Accordion title="No proxying into private networks">
    The one tool that fetches a caller-supplied URL (`verify_widget_install`) resolves the hostname first and refuses loopback, link-local, and private addresses, re-checking every redirect hop. The server cannot be used to reach a network it can see and you cannot.
  </Accordion>

  <Accordion title="Untrusted content is fenced">
    Results that carry third-party text — website-visitor questions, crawled pages, test-drive transcripts — are wrapped in an explicit untrusted-content marker telling the agent to treat them as data and never as instructions.
  </Accordion>

  <Accordion title="Reversible by design">
    The onboarding flow writes nothing before explicit approval, and every Mira settings change returns a snapshot that `restore_mira_settings` can put back.
  </Accordion>
</AccordionGroup>

## Troubleshooting

<AccordionGroup>
  <Accordion title="MEETERGO_TOKEN is not set">
    The token never reached the server. In a config file it belongs inside the `env` block; against the hosted endpoint, check the header reads `Authorization: Bearer rgo-…`.
  </Accordion>

  <Accordion title="401 Unauthorized">
    The token is wrong, was revoked, or was pasted with whitespace. Create a fresh one at [Integrations → API](https://my.meetergo.com/integrations). The `WWW-Authenticate` header on the response names the reason.
  </Accordion>

  <Accordion title="A tool reports a missing capability">
    The token was scoped without that capability group. Create a new token that includes it.
  </Accordion>

  <Accordion title="The test drive is rate-limited">
    It runs several real conversations, so it is capped at a few runs per hour per company. The saved configuration is unaffected.
  </Accordion>

  <Accordion title="propose_conversion_setup could not read the site">
    If the site is public and renders normally, this is almost always our model lane being slow rather than anything wrong with the website. Retry in a moment.
  </Accordion>
</AccordionGroup>

## Source

Open source at [github.com/meetergo/meetergo-mcp-server](https://github.com/meetergo/meetergo-mcp-server), published as [`@meetergo/mcp-server`](https://www.npmjs.com/package/@meetergo/mcp-server).