Slab MCP Server

Slab

Internal knowledge base: organization → topics → posts. Members are users. Slab exposes one GraphQL endpoint; content is stored as Quill Delta JSON on posts.

Operational order

1. Confirm workspace context with the organization read when you need the workspace name or entry point.
2. Search when the user describes a topic in natural language; list or fetch posts when you already have ids or need pagination across the library.
3. Topics group posts — fetch a topic by id to list posts inside that topic.
4. Users are directory lookups only (id, name, email); use for attribution on posts, not for editing membership via API.
5. Updates change post body content only through the update mutation — there is no public create-post mutation on this API surface.

Pagination

List and search operations use cursor pagination: pass after with the previous next_cursor until has_more is false. Default page size is 25; maximum 100.

Content shape

Post bodies are Quill Delta. Read tools can return plain_text (derived from Delta) when full content is included. For programmatic edits, pass Quill Delta JSON to the update tool exactly as Slab expects.

Slab Bot and private topics

API results mirror what the Slab Bot user can see. Missing posts usually mean Bot lacks access to that topic — fix permissions in Slab, not in MCPBundles.

Webhooks (Slab → MCPBundles)

Slab registers outbound webhooks in Team settings → Developer (no GraphQL webhook CRUD). Use the inbound webhook info read when you need the HTTPS URL to paste into Slab. MCPBundles accepts POST callbacks on that route for post-published and related events; automation handlers will consume them in a later release. When Slab supplies a webhook signing secret, MCPBundles platform operators configure verification server-side — not in the Slab credential form.

Plan requirement

GraphQL access requires Business or Enterprise. Free/Starter workspaces receive HTTP 403 from the API.