Skip to main content
The Klarity MCP is a read-only view into your organization’s process intelligence. This page is the canonical reference for security, architecture, and access-control questions — written so InfoSec, IT, and platform reviewers can use it directly.

​
Integration scope

The MCP does not integrate with external LLMs directly. Your AI client (Claude, ChatGPT, Cursor, and so on) connects to the MCP and uses whatever LLM that client runs. The MCP supplies process intelligence; the client supplies the model. Supported clients today:
SurfaceClients
IDEs / CLIsClaude Code, Codex, Cursor, Gemini CLI
Conversational assistantsChatGPT (via the OpenAI app store); Claude (via the Anthropic connector directory)
If the AI client doesn’t run inside an IDE, the MCP plugs into the assistant’s app/connector layer instead. The connection model is the same in either case: the client talks to a single MCP endpoint over HTTPS using the Model Context Protocol.

​
Architecture

The MCP runs on the same infrastructure that powers the Klarity Architect web application you already use. There is no separate data plane.
PropertyValue
TransportHTTPS-based Model Context Protocol over TLS
Endpointhttps://api.klarity.ai/mcp
BackendSame API and data store that serves the Klarity Architect web application
Every MCP request flows into the same backend as a request from the web app. There is no shortcut path that bypasses normal validation or access control.

​
Authentication

Two methods are supported. Pick based on whether the session is interactive or automated.
MethodWhen to use
OAuthRecommended for human, interactive sessions. Same sign-in flow as the Klarity web app — the AI client manages the token after sign-in.
Long-lived API keyRecommended for background or automated agents. Generated from Settings → MCP in Klarity. Sent as a Bearer token on every request.
API keys are revocable at any time from the same Settings → MCP screen. See Authentication for per-client setup details.

​
Authorization

Authorization is enforced by the same layer as the Klarity Advisor web application. The MCP can only access what the authenticated user — or, for API keys, the user the key was issued for — can access in the web app:
  • Workspace boundaries are enforced identically. MCP requests cannot read across workspaces the user is not a member of.
  • Per-resource permissions are enforced identically. If a user cannot see a process, observation, artifact, or graph entity in the web app, the MCP returns the same answer.
  • There is no MCP-only access path that bypasses the normal authorization layer.
In short, the MCP inherits the user’s existing posture. Granting MCP access does not broaden what a user can already see.

​
Read-only data scope

All tools exposed by the MCP in production are read-only. The MCP does not modify user-facing data and cannot read across workspaces — each connection is scoped to a single workspace, set by the authenticated user’s session or the workspace the API key was issued for. The MCP cannot:
  • Create or modify processes, artifacts, observations, or graph entities
  • Edit policies, attributes, or workspace configuration
  • Invite users, manage roles, or change permissions
All write operations happen in the Klarity Architect UI. See Limitations for the full out-of-scope list.

​
Summary for reviewers

  • Connection: AI client ↔ Klarity MCP over HTTPS + TLS. No direct external LLM integration; LLMs live inside the AI client.
  • Hosting: Same infrastructure as the Klarity Architect web application.
  • AuthN: OAuth (interactive) or long-lived API key (automated). Both revocable from Settings → MCP.
  • AuthZ: Identical to the Klarity web app — same workspace and per-resource permissions.
  • Data scope: Read-only. Cannot bypass user permissions.
If your review needs detail not covered here, reach out at hello@klarity.ai.