Glide MCP

The Glide MCP server lets an AI agent operate Glide directly: triage and move requests, edit documents, manage roadmap items and cycles, post comments, and more. It speaks the Model Context Protocol over Streamable HTTP — hosted, so you can connect with just a URL and an API key — or over stdio for local development. Any MCP-capable client (Claude Code, Claude Desktop, and others) can drive Glide the same way a person does.

It lives in the monorepo at apps/glide-mcp (@systeric/glide-mcp).

Setup

1. Get an API key

In Glide, go to Account settings → API keys → Create key. The key (sk-…) is shown once, so copy it somewhere safe — you’ll paste it into your MCP client’s config next.

2. Register the hosted endpoint

No install, build, or file path needed. Add it to your MCP client’s config (for Claude Code, .claude.json):

{
  "mcpServers": {
    "glide": {
      "type": "http",
      "url": "https://glide.systeric.com/mcp",
      "headers": { "Authorization": "Bearer sk-…" }
    }
  }
}

That’s it — the endpoint authenticates each request by the bearer key you pasted in.

Run it yourself (local stdio)

For contributors working on the server itself, run it locally over stdio instead. It needs one secret and accepts an optional host override:

{
  "mcpServers": {
    "glide": {
      "command": "node",
      "args": ["/path/to/apps/glide-mcp/dist/index.js"],
      "env": { "GLIDE_API_KEY": "sk-…" }
    }
  }
}

The client launches the server per session. After building (or pulling a new build), restart the client to pick up changes.

What you can do

The tools mirror the things you’d do in Glide by hand. A selection:

• Requests — list_requests, get_request, create_request, start_request, resolve_request, update_request_status, update_request_priority
• Comments — list_comments, create_comment
• Documents — list_documents, get_document, create_document, update_document
• Roadmap & cycles — list_roadmap_items, get_roadmap_item, list_cycles, get_current_cycle
• Updates, todos, notifications, people, audit — read and, where it makes sense, write

Reads return the entity’s data (including its current version, see below). Writes go through the same API the web app uses, so permissions and validation are identical.

Safe concurrent edits

Because agents and people edit the same requests and documents at the same time, the guarded write tools support optimistic concurrency so one side never silently overwrites the other.

Each entity carries a version. The guarded write tools accept an optional baseVersion: pass the version you last read, and if the record changed since then, the write is rejected with a clear conflict instead of clobbering the newer edit.

Flow:

1. Read the entity (e.g. get_request) and note its version.
2. Write with baseVersion set to that version.
3. If you get Conflict: … (current version N). Refetch and retry., re-read and try again on the new version.

Omit baseVersion to keep the legacy last-write-wins behavior.

Guarded tools today: start_request, resolve_request, update_request_priority, update_document.

Develop

pnpm --filter @systeric/glide-mcp build      # tsc -> dist/index.js
pnpm --filter @systeric/glide-mcp test       # vitest
pnpm --filter @systeric/glide-mcp typecheck

Layout:

• src/server-factory.ts — shared tool wiring used by both entry points below
• src/index.ts — stdio entry point (local dev)
• src/http.ts — stateless Streamable HTTP entry point, mounted at /mcp by apps/api
• src/tools.ts — tool definitions and the dispatcher
• src/api-client.ts — the API client and conflict surfacing