Klavis AI: MCP integration, Strata, and the self-hosted path

What Klavis solves, and for whom

An agent that needs to read Gmail, post to Slack, and drive a browser has three problems that have nothing to do with the model: OAuth token storage per end user, a stable tool schema the model can call, and a way to keep the tool list from eating the context window. Klavis is aimed at that layer rather than at the agent itself. The README frames the project as three products: Strata, described as connectors that optimise the context window; MCP Integrations, described as more than one hundred prebuilt integrations with OAuth support; and MCP Sandbox, described as scalable MCP environments for LLM training and reinforcement learning. The intended user is a developer wiring an agent framework to real accounts. The examples directory is the clearest signal of who that is: there are separate example folders for LangChain, LlamaIndex, CrewAI, Agno, Mastra, Google ADK, the Google Gemini CLI, OpenAI, Fireworks, and Together. If your stack is on that list, the integration path is already sketched.

How an MCP server instance is created and what sits behind it

The mechanism is a server instance keyed by user. You call the API or SDK with a server name and a user_id, and you get back an MCP endpoint that the agent connects to as a normal MCP client. The user_id is the join key: it is how Klavis knows which Gmail or Slack account the tools should act on, and it is why the OAuth step happens per user rather than per application. Strata sits above that. Instead of handing the model every tool from every connector, you create a Strata instance over a set of servers, and the connector layer decides what the model sees. The README describes Strata as optimising the context window, and the repository keeps it under open-strata/ as a separately installable component, which is the part you can run without the hosted service. The mcp_servers/ directory holds the individual integration implementations. Two documents in the root, LLM.md and MCP_SERVER_GUIDE.md, plus the _oauth_support/ and mcp-clients/ directories, are where the repository puts the detail the README omits.

Installing Strata locally and running a first connector

The README gives three self-host routes. The simplest is the published container for a single integration. It exposes port 5000.

docker pull ghcr.io/klavis-ai/github-mcp-server:latest
docker run -p 5000:5000 ghcr.io/klavis-ai/github-mcp-server:latest

After that, the MCP endpoint is on local port 5000 and your agent connects to it like any other MCP server. The second route installs the open source Strata binary with pipx, then registers a stdio server by name. The README uses Playwright as the example.

pipx install strata-mcp
strata add --type stdio playwright npx @playwright/mcp@latest

The --type stdio flag tells Strata the server speaks over standard input and output rather than HTTP, and the command after the server name is the process to launch. You should see the server registered locally once the command returns. The third route is the SDK, which targets the hosted service and needs an API key.

from klavis import Klavis
from klavis.types import McpServerName

klavis = Klavis(api_key="your-key")

gmail = klavis.mcp_server.create_server_instance(
    server_name=McpServerName.GMAIL,
    user_id="user123",
)

The returned object is the instance your agent talks to. Note that the README's own Python snippet is inconsistent: it assigns the client to klavis and then calls klavis_client.mcp_server.create_strata_server, a name that was never bound. Treat the Strata call in that block as illustrative and check the Python SDK source before copying it.

The self-host story is narrower than the marketing implies

The README's self-host section shows exactly one integration container, github-mcp-server, plus the Strata binary. It does not show how to run the other hundred-odd integrations yourself, and it does not describe a bulk export or a compose file for the full catalogue. The cloud option and the REST API both point at api.klavis.ai, so the default path for anything beyond that one container is the hosted service. That is a real constraint if your organisation will not send end-user OAuth tokens to a third party. It is also a constraint for air-gapped environments. The repository does contain the integration implementations under mcp_servers/, so self-hosting more of them may be possible by building from source, but the README does not document that workflow and it is not possible to confirm from the repository that it is supported. A second limitation is the user_id model itself: it is an opaque string you supply, and the documentation shown here does not describe what happens on deletion, key rotation, or account unlinking. If you need per-tenant data residency, that is the question to ask before you build on it.

Where it fits against building MCP servers yourself

The alternative is the official MCP servers and the MCP SDKs, wired directly into your agent. The difference is where the work sits. With the official servers you own the OAuth application, the token store, and the per-user mapping; you get full control and no third party in the credential path, and you pay for it in the weeks it takes to get a dozen integrations through review. Klavis trades that control for a hosted credential layer and a single API surface across integrations. The trade is worth it when you need breadth quickly and your users are already comfortable with a hosted tool provider. It is the wrong trade when the integrations are the product, or when a single connector needs behaviour the prebuilt server does not expose. Strata is the more interesting piece for anyone who wants neither extreme: it is published as a pipx-installable binary, so you can keep the context-window management locally while deciding separately whether to use the hosted integrations.

Licence, maintenance, and the cost of upgrading

The repository is Apache-2.0, which permits commercial use and modification with the usual attribution and notice requirements. That is the repository-level licence; the README does not state a separate licence for the hosted service or for the individual integration containers, and the LICENSE file is the authority on what the Apache grant actually covers. Do not assume the hosted API terms match the source licence. On maintenance: the last push to the default branch was on 2026-01-29, and the most recent releases listed are python-v2.20.0 and ts-v2.20.0 on the same date, with ts-v2.19.0 before that on 2026-01-06. The project is not archived, but the release cadence has a gap between January and now that is worth knowing if you depend on new integrations landing quickly. Upgrade cost is mostly SDK surface. The Python and TypeScript SDKs are versioned in lockstep, so a bump in one usually means a matching bump in the other if you run both. Because the hosted service and the SDKs share version numbers, pinning the SDK and reading the release notes before upgrading is the cheap insurance.

Editorial conclusion

Adopt Klavis if you are building an agent that needs hosted OAuth-backed connectors and you are comfortable sending user credentials through a third party, or if you want the open source Strata binary running locally next to your agent. Do not adopt it if you need a fully self-hosted, licence-audited stack today: the README points only to a hosted API and a single published container image, and the repository does not document an offline deployment of the full integration catalogue. Before committing, verify two things in the source tree: whether the specific integration you need has an OAuth flow you can redirect to your own domain, and what the LICENSE file says about the mcp_servers directory versus the open-strata directory, because those are the two pieces you would actually ship.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes