Meetergo MCP Server

meetergo MCP server

Lets an AI agent actually run a calendar: find slots, book, reschedule, cancel, review what is coming up, and keep the contact record straight.

Not to be confused with the docs MCP server at https://developer.meetergo.com/mcp, which searches documentation and cannot change anything. Both are useful and they do different jobs:

Setup

Create a Personal Access Token at my.meetergo.com/integrations — it looks like rgo-… — then either point your client at the hosted server or run this package locally over stdio. The token works on every plan, including Free.

Hosted

https://mcp.meetergo.com/mcp

Streamable HTTP, authenticated with Authorization: Bearer rgo-…. The path matters: mcp.meetergo.com alone is not the endpoint. For clients that take a remote URL and headers:

{
  "mcpServers": {
    "meetergo": {
      "url": "https://mcp.meetergo.com/mcp",
      "headers": { "Authorization": "Bearer rgo-your_token_here" }
    }
  }
}

Local (npx)

{
  "mcpServers": {
    "meetergo": {
      "command": "npx",
      "args": ["-y", "@meetergo/mcp-server"],
      "env": { "MEETERGO_TOKEN": "rgo-your_token_here" }
    }
  }
}

Works with Claude Desktop, Claude Code, Cursor, or anything else that speaks MCP.

Scope the token

When you create the token you can limit it to the capabilities the agent actually needs (scheduling, contacts and deals, Mira, forms, account). A limited token is refused on everything outside those groups, including reads, so give it every group whose tools you intend to use — a Mira-only token cannot book, and a scheduling-only token cannot read your knowledge base.

Signing in instead of pasting a token

Not yet. The hosted endpoint authenticates with a Personal Access Token or a Platform API Key today, and nothing else. OAuth sign-in is not enabled on it, so a host that probes for it is told so — /.well-known/oauth-protected-resource answers 404 — rather than being walked into an authorization flow that cannot finish.

When it is enabled it will need no credential from support: the connector takes a public client id published on this page, with no client secret. There is no dynamic client registration either way.

A Personal Access Token works in every MCP client, on every plan including Free. That is what the rest of this page assumes.

Acting for another user

A Personal Access Token always acts as its owner. To run an agent across a whole company — an assistant booking on behalf of several colleagues — use a Platform API Key (ak_live:<uuid>:<secret>) and name the target user:

"env": {
  "MEETERGO_TOKEN": "ak_live:...",
  "MEETERGO_USER_ID": "the-user-uuid"
}

The two token types have opposite requirements, and the server checks both at startup rather than letting you find out mid-booking:

• a Platform API Key must have MEETERGO_USER_ID — the API demands an acting user on nearly every route;
• a Personal Access Token must not — it always acts as its owner, and the API rejects the header outright.

Against the hosted endpoint the acting user travels as the X-Meetergo-Api-User-Id request header instead of an environment variable; the same two rules apply, and sending it with a Personal Access Token is refused.

Environment

The stdio entry (meetergo-mcp, what npx runs):

Running the hosted entry yourself

The package also ships meetergo-mcp-http, the Streamable HTTP entry that runs behind https://mcp.meetergo.com/mcp. Credentials arrive per request in the Authorization header rather than from the environment, so one process serves any number of accounts — MEETERGO_TOKEN and MEETERGO_USER_ID are not read here. It reads:

The three OAUTH_* variables are all-or-nothing. Set all three and an inbound access token is validated first — issuer, aud, typ: Bearer, RS256 signature against the issuer's JWKS, expiry — and only then exchanged for a separate token for the upstream API. The MCP spec forbids forwarding the token a client handed you, so the exchange is not an optimisation; it is the only path.

Set none and the process is bearer-token-only: Personal Access Tokens and Platform API Keys work, both .well-known paths answer 404, the 401 challenge carries no resource_metadata, and an OAuth token is refused rather than passed upstream.

Set one or two and you get the bearer-token-only behaviour above, not a partial OAuth — plus a warning log, oauth_disabled_incomplete_config, naming the variables that are missing.

Retries

Both entries behave the same here. Rate limits and transient upstream errors (429, 502, 503, 504) get up to three attempts in total (so two retries), honouring Retry-After where the API sends one.

Retries are not applied blindly. A booking or cancellation that fails ambiguously — a timeout, a dropped connection, a 502 — may already have been applied by the API, and there is no idempotency key to make a second attempt safe. Only reads are retried on those; writes are retried solely on a 429, the one response that states the request was never processed.

One-prompt onboarding

If your client supports MCP prompts, run meetergo: onboard. Otherwise paste this:

Set up meetergo for my company. Call get_me and get_setup_status first and tell me what already exists. Then analyse my website with propose_conversion_setup and present the proposed setup — meeting types, qualification questions, the website assistant. Build nothing until I approve. After I approve: create what's missing, turn the questions into a routing form with create_qualification_form, crawl my site, then PROVE it works with run_test_drive and show me the verdicts. Finish by giving me the install snippet, and verify with verify_widget_install after I've pasted it.

The agent audits what exists, proposes, waits for your yes, builds, and then shows you scripted visitors booking through your own assistant before anything goes live. A second prompt, meetergo: weekly-review, pulls last week's conversations and offers to teach the assistant every answer it missed.

Plan limits

Every tool reports plan walls structurally: which limit was hit and where upgrading happens, so your agent explains the situation instead of failing vaguely. get_me also returns a plan block (tier, limits) so a good agent warns you before starting something your plan cannot finish. Connecting the server itself is never gated — a token from any plan, including Free, works.

Tools

56 tools, covering scheduling end to end. Scheduling is the loop most agents live in; the rest is there so an agent never has to fall back to raw REST.

Scheduling

Follow-up

Meeting types

Booking page

Routing forms

CRM

Mira, the website assistant

Everything needed to take a website from "no assistant" to a live one that answers from the company's own pages and books meetings.

Knowledge base

Webhooks

Writes carry readOnlyHint: false, and everything marked destructive above carries destructiveHint: true, so hosts can require confirmation before an agent removes something a human would miss.

What the tools do for you

The API asks for things a model has no way to know. Rather than describing that boilerplate in a docstring and hoping, the tools supply it:

• book_appointment builds the nested attendee object, defaults receiveReminders and the required empty notes, and refuses a booking with no name rather than writing a blank one into the invitation.
• get_availability and book_appointment resolve which hosts to compute for. The API rejects both with Expected hostIds or queueId before it even loads the meeting type, and a model only ever has a meetingTypeId.
• create_meeting_type fills the six required-but-irrelevant meetingInfo fields (customChannelName, connectChannelName, an empty confirmationButton, …) that reject the whole request when missing. Anything the schema does not name goes through advanced.
• list_appointments supplies the required page and pageSize, which the API has no defaults for.

Development

npm test          # vitest
npm run build     # tsc -> dist

The tests assert the wire format, not just the tool list: which path each tool calls, and the exact body shape the API's DTOs require. That is deliberate. 0.1.x shipped five tools that could never succeed — wrong paths, wrong query keys, a flat body where BookingDto wants a nested attendee — and every test passed, because they only ever checked that the tools existed. Adding or changing a tool means pinning its request against the route in apps/api.