Skip to main content
MCP hero MCP (Model Context Protocol) is an open-source standard for how applications provide context and tools to LLMs. The Openlayer MCP server exposes many of Openlayer’s features to LLMs. If you use an IDE or desktop app with MCP support — like Cursor, VSCode, Claude Desktop, and others — you can now directly interact with your Openlayer workspace without leaving your editor. Openlayer MCP in Cursor There are two ways to run it: Use the remote connector unless you need those two local-only tools or you’re running a self-hosted Openlayer instance. The Openlayer MCP server is available as a hosted, OAuth-protected remote connector — no local install, no API key. Add it by URL in any MCP client that supports remote servers:
On first use, your client registers itself and takes you through your normal Openlayer login. You then pick:
  • which workspace the connection is for, and
  • whether to grant full or read-only access.
Both choices are fixed for the lifetime of that connection — nothing in the chat can re-point it. To work in a second workspace, add a second connector and authorize it for that workspace; the two coexist, and list_workspaces shows which workspace a connection is bound to. You can review and revoke connections per workspace in Openlayer under Settings → Security → Connected apps.
In claude.ai or the Claude desktop app, go to Settings → Connectors → Add custom connector and enter https://mcp.openlayer.com/mcp.

​
What differs from local

Two tools are intentionally not exposed on the remote connector:
  • push_commit reads a directory on the machine running the tool — your own machine over stdio, but a shared server in remote mode. Instead, the remote connector exposes create_presigned_upload_url and finalize_commit: your client uploads the project bundle itself, then creates the commit from the returned storage_uri. This only works in clients that have their own file and shell access (like Claude Code).
  • call_openlayer_api, the freeform API escape hatch, takes an arbitrary HTTP method. Use the local server for direct API access.

​
Local set up

Prefer running the server locally — for direct API access, push_commit, or an air-gapped setup? To get started with the local Openlayer MCP server:
1

Install uv

Make sure you have uv installed in your machine. You can follow the instructions here if you don’t have it yet.
2

Add Openlayer to your MCP configuration

Add the following snippet to your mcp.json configuration file.The location of this file depends on your editor. For example, for Cursor, this is ~/.cursor/mcp.json. For VSCode, this is ~/.vscode/mcp.json.
If you use Claude Code, you can register it with a single command instead:
3

Restart your application

Some applications require you to restart the application after adding the configuration.
The local server reads two environment variables:

​
Self-hosted Openlayer

If you run Openlayer on-premise, you can serve the remote connector from your own deployment as well: it’s an opt-in container on every deployment target, and it’s served from the URL you already use for Openlayer, at <OPENLAYER_URL>/mcp. It authenticates against your own backend’s OAuth2 Authorization Server, so there’s no external identity provider, no second hostname, and no client to register. See the “Deploying the MCP connector” section of your on-premise deployment repository’s README, or reach out to us, for the setup steps. The local server also works against a self-hosted instance — set OPENLAYER_BASE_URL to your Openlayer URL.

​
Usage

Once configured, you’ll be able to see and use the Openlayer MCP server inside your application. You can ask it to:
  • List and create projects, and inspect their commits.
  • List, create, and inspect data sources (inference pipelines), and fetch their production traces, sessions, and per-user activity, with filters.
  • List and create tests — integrity, consistency, performance, and LLM-as-a-judge — trigger evaluation, read results, and drill into the rows that failed.
  • Search the Openlayer documentation.
Tools are annotated as read-only or destructive, so clients can auto-approve reads and ask you to confirm writes.