MCP setup by client#
The server is the same everywhere: npx -y @laver/mcp with your key in
LAVER_API_KEY. What differs between clients is where that configuration
lives and how the client picks it up — which is the part people actually get
stuck on. This page is those differences, one client at a time.
MCP server covers what the server can do
once it is connected; you will need a key from Admin → API keys first, and
npx means the machine running the client needs Node installed.
One rule applies to every client on this page: the configuration is read when the server starts, not while it runs. Editing it inside a session that is already open changes nothing — restart the session or the app afterwards.
Claude Code#
One command, from your project directory:
claude mcp add laver -e LAVER_API_KEY=your-key-here -- npx -y @laver/mcp
By default that registers the server for you, in this project only. The
--scope flag chooses wider:
--scope user— every project on this machine, still only you.--scope project— writes a.mcp.jsonat the project root, which is meant to be committed so the whole team gets the server. Do not put the key in it. Use-e LAVER_API_KEY_FILE=/path/to/.envinstead of-e LAVER_API_KEY=…, and let each person's gitignored.envcarry their ownLAVER_API_KEY=…line — a key acts as the person who created it, so sharing one literal key would make everyone's work attributable to whoever minted it.
claude mcp list shows what is registered and whether it connects; inside a
session, /mcp does the same.
Claude Desktop#
Claude Desktop reads a JSON file. Settings → Developer → Edit Config opens it; on disk it is:
- macOS:
~/Library/Application Support/Claude/claude_desktop_config.json - Windows:
%APPDATA%\Claude\claude_desktop_config.json
Add the server to it — if the file already has an mcpServers object, add
"laver" inside the existing one:
{
"mcpServers": {
"laver": {
"command": "npx",
"args": ["-y", "@laver/mcp"],
"env": { "LAVER_API_KEY": "your key here" }
}
}
}
Then quit Claude Desktop fully and reopen it — closing the window is not
always quitting the app, and a half-restart is the usual reason the tools do
not appear. The first start after adding the server is slower than the rest:
that is npx fetching the package once.
Cursor#
Same JSON shape, different file:
- One project:
.cursor/mcp.jsonin the project root. - Everywhere:
~/.cursor/mcp.json.
Cursor also has a settings screen for this (Cursor Settings → MCP), which
writes the same files. As with Claude Code's .mcp.json, a project-level file
may end up committed — keep the key out of it with LAVER_API_KEY_FILE
pointing at a gitignored file that holds a LAVER_API_KEY=… line.
Any other MCP client#
Laver's server is a standard stdio MCP server, so any client that can run a
command can use it: command npx, arguments -y @laver/mcp, and
LAVER_API_KEY in the environment. There is no hosted endpoint — the server
runs next to the client and talks to https://api.laver.app itself — so a
client that only supports remote HTTP servers cannot connect directly.
Checking it worked#
Ask the assistant to list your Laver workspaces. list_workspaces takes no
arguments, so it is the cleanest first call: if it answers, the server is
running and the key is good. If it does not:
- The tools are not offered at all — the client has not started the
server. Restart the session or the app; if that changes nothing, check the
config file is the one the client actually reads and that
npxis on thePATHthe client launches with. - The key was rejected — the refusal says so, verbatim: missing, mistyped, revoked, expired, or a placeholder never filled in. Mint a new key under Admin → API keys and restart the client.
- A
403naming another workspace — working as designed. A key is confined to the one workspace it was created for, even if its owner belongs to others; create a second key for the second workspace.
From there, the agent quickstart is the same ground without a client in the way, and concurrency and polling is what to read before letting an agent write to a board people are using.