MCP server

Connect an MCP-compatible AI assistant to a running Meetily desktop app: tools, resources, prompts, and the security model behind them.

meetily:// is not meetilypro://

The MCP resource scheme meetily:// (meetily://meetings, meetily://meeting/{id}, and so on) is unrelated to meetilypro://, the OS-level deep-link scheme gated by its own deeplink_enabled setting. Don't conflate the two - one addresses MCP resources inside a running server, the other is a system link handler.

meetily-pro mcp runs a local stdio Model Context Protocol server that lets an MCP-compatible assistant (Claude Desktop, Claude Code, Cursor, and similar clients) drive a running Meetily desktop app: read meetings and transcripts, control recording, manage summaries and jobs, and more.

It is a thin wrapper around the same Gateway HTTP API the meetily-pro CLI uses - see meetily-pro CLI. It never touches the database directly, so it inherits the Gateway's Pro license gate and per-route scopes for free.

Requirements

The Meetily desktop app must be running with Integrations enabled - turn that on in Settings > Integrations, see Enable & connect. That's what brings up the Gateway on loopback (127.0.0.1:8420), which the MCP server reaches everything through.

If the app isn't running, tools/list still works (it's served from a compiled-in manifest), but each tool call returns a clear "Gateway unreachable" error instead of hanging.

meetily-pro mcp install also needs the app running: it mints the client's scoped token through the Gateway, and fails closed - writing nothing - if the Gateway is unreachable. A client is never left wired to an over-privileged fallback token.

Quick start

Register meetily-pro as an MCP server in your client's config. This mints a scoped, per-client token through the Gateway rather than handing the client the all-scopes local token:

meetily-pro mcp install            # read-only grant
meetily-pro mcp install --write    # also grants write

Restart your MCP client. It launches meetily-pro mcp --token-file <path> over stdio using the entry install wrote.

If a tool call fails, run meetily-pro mcp doctor to check Gateway reachability, Pro license tier, and the token's scopes in one pass.

mcp install merges its entry into the client config's server map without clobbering any server you already have there, and writes atomically (temp file plus rename), so a partial write can never truncate your config.

What it exposes

Tools

The tools are generated at runtime from the gateway's OpenAPI manifest, not hand-listed, and a completeness test locks the set to the real routes so it can't silently drift. The current shape is roughly 34 tools (about 16 read, 16 write, 2 bounded-wait). The 5 webhook tools are gated off by default, so a default server advertises around 29; pass --allow-webhooks to expose the webhook tools too.

Get the exact set from the server, not from this page

Because the set is generated per build, the authoritative list is whatever your server reports. Run tools/list from your client, or meetily-pro mcp doctor, to see the exact tools and scopes your build exposes.

Representative tools by category:

whoami, list_meetings, get_meeting, get_transcript, get_summary, export_meeting, search_transcripts, get_config, list_jobs, get_job, list_devices, list_models, get_recording_state, list_webhooks, list_webhook_deliveries, and similar read views.

rename_meeting, set_summary, regenerate_summary, set_speaker_labels, submit_diarization, cancel_job, pause_job, resume_job, retry_job, start_recording, stop_recording, pause_recording, resume_recording, plus the webhook write tools below.

wait_for_job, wait_for_recording - each resolves on the underlying event or a bounded timeout (default 30s, capped at 600s), so neither one blocks open-ended.

The webhook tools (list_webhooks, list_webhook_deliveries, create_webhook, delete_webhook, test_webhook) are all-or-nothing as a group, hidden unless --allow-webhooks is set.

A newly connected assistant defaults to read only

Install without --write and the client can only call the 16 read tools. Pass --write at install time to also grant the 16 write tools, including recording control and summary edits.

Delete is never a tool

The two destructive deletes - deleting a meeting and deleting a pairing - are never registered as MCP tools, in any mode. Delete is not something an assistant can reach through this server, by design. Each registered tool also carries MCP annotation hints (readOnlyHint, destructiveHint, idempotentHint, openWorldHint).

Read-only mode

meetily-pro mcp --read-only

This is a real guarantee, enforced in two places: write tools are hidden from tools/list, and they're also refused if a client calls one anyway by ID.

Resources

URI-addressable read views under the meetily:// scheme:

meetily://meetings - all meetings
meetily://meeting/{id}
meetily://transcript/{id}
meetily://summary/{id}

Prompts

Two canned workflows, each taking a meeting_id and referencing that meeting's transcript resource:

summarize_meeting
extract_action_items

Commands

Command	What it does
`meetily-pro mcp`	Serve over stdio. Read and write tools are both exposed unless `--read-only` is passed.
`meetily-pro mcp --read-only`	Serve with only read tools - hidden from `tools/list` and refused at call time.
`meetily-pro mcp --allow-webhooks`	Also expose the 5 webhook tools.
`meetily-pro mcp install [--config <path>] [--name <name>] [--write]`	Register the server in a client config and mint a scoped per-client token for it (read only by default; `--write` also grants write). Requires the app running, and fails closed if it isn't.
`meetily-pro mcp doctor`	Probe the Gateway and report reachability, Pro license tier, and the token's scopes, with remediation. Distinguishes a reachable-but-denied Gateway (token or license problem) from an unreachable one (app not running).

Security model

The server reaches meeting data only through Gateway HTTP routes, so it inherits the Pro license gate and per-route scopes rather than re-implementing either.
tools/list is filtered to the calling token's actual scope, checked through the Gateway's whoami route, and fails safe to read-only if that check itself fails.
--read-only is enforced by the server in both places it matters - what's advertised in tools/list, and what's actually allowed when a tool is called - so it holds even against a client that ignores the advertised list.
mcp install never writes a client to an over-privileged fallback: if the Gateway is unreachable when you run it, it writes nothing rather than falling back to a broader token.

On this page