MCP Integration

DiagramKit exposes its manual workspace operations over the Model Context Protocol (MCP). A connected client acts with your account's existing workspace permissions. It can read or edit diagrams and models, documents, brainstorms, presentations, sprint work and other available workspace resources according to its granted scopes.

Connect a client

1. Sign in to DiagramKit and make sure you have access to the workspace you want to use.
2. Add https://api.diagramkit.dk/mcp as a remote HTTP MCP server in your client.
3. Complete the client's OAuth sign-in and consent flow through the configured Clerk authorization server. The client must support OAuth discovery, PKCE and Client ID Metadata Documents (CIMD), or use a client registration arranged by the operator. Automatic Dynamic Client Registration (DCR) is disabled.
4. Request the minimum scopes needed for your task, then discover the tools and their input schemas with tools/list.

The resource metadata is at https://api.diagramkit.dk/.well-known/oauth-protected-resource/mcp. Access tokens must target the resource https://api.diagramkit.dk/mcp. A browser session cookie or a token issued for another service is not an MCP credential. See the MCP authorization specification for the client protocol.

For a CIMD-capable client, use the public HTTPS client metadata document URL supplied by that client as its client ID. Its registered redirect URI must match the callback used in the authorization flow. Clients that only support DCR need an operator-configured registration. Normal grants include read access and identity scopes; request write access only for editing. Request offline_access only if the client needs refresh tokens.

Permissions

The ordinary CIMD client grant permits read/write scopes; it does not advertise or grant diagramkit:admin.

Scopes do not grant workspace membership or change a viewer into an editor. Tools outside the granted scopes are omitted from discovery. The same authorization checks apply when a client calls the underlying REST API directly.

Read, edit and export

Tool names follow the discovered controller/action names. Inputs group route parameters under path, URL parameters under query and JSON payloads under body. Follow the returned schema rather than adding your own account or workspace authority fields.

For example, the discovered render_render tool accepts:

{
  "path": { "id": "your-flow-id" },
  "query": { "format": "svg" }
}

The server exports the saved diagram and its shared model together. Results include HTTP status, content type, encoding and body. SVG is returned as text; PNG and PDF bodies use base64. The renderer accepts diagrams up to 500 nodes and 1,000 edges, with bounded time and output size; busy or oversized requests return an error instead of queuing unlimited work.

Diagrams, documents, presentations, brainstorms and planning items require the revision you read before making a change: body.expectedRevision on updates and query.expectedRevision on deletion. Missing or stale revisions return 409. UML edits also carry the current model revision. Reconcile intended changes against the latest state; never fetch a new revision only to overwrite a conflict.

The resourcehistory_list, resourcehistory_get and resourcehistory_restore tools expose the same authorized version history as the website. Inspect a version before restoring and send its currentRevision as expectedRevision. Include currentModelRevision as expectedModelRevision when present. Restoration creates a new version and requires write scope plus Editor or Owner membership. A UML restore also changes the shared workspace model; check the affected views.

Disconnect or revoke the client's grant through its OAuth account controls when access is no longer needed. Keep access and refresh tokens in the client's credential storage, never in diagram content or shared configuration.