MCP server

For agents that can't run shell commands — Claude Desktop, or any other client that speaks the Model Context Protocol — the CLI ships lindris-mcp, a server that exposes the command tree as MCP tools.

lindris-mcp shells out to the same lindris binary, so an agent runs the exact commands you would, with the same auth and the same output. A few commands are withheld from the tool list — see What the tool surface withholds. (Using Claude Code? Prefer the Claude Code or Codex plugin — no server needed.)

Claude Desktop

The quickest way to give Claude Desktop the Lindris tools is the prebuilt bundle. Download the .mcpb for your platform:

curl -fL -o lindris-mcp.mcpb https://a.lindris.com/cli/mcpb/<os>/<arch>

Pick <os>/<arch> for your machine:

Your machine	URL
Mac — Apple Silicon (M1/M2/M3/M4)	https://a.lindris.com/cli/mcpb/darwin/arm64
Mac — Intel	https://a.lindris.com/cli/mcpb/darwin/amd64
Linux — x86_64	https://a.lindris.com/cli/mcpb/linux/amd64
Linux — ARM (Raspberry Pi, Graviton, ...)	https://a.lindris.com/cli/mcpb/linux/arm64

Not sure? uname -sm prints your OS and architecture (Darwin arm64 → darwin/arm64; x86_64 means amd64).

Open the downloaded file in Claude Desktop under Settings → Extensions. Desktop prompts for your LINDRIS_API_KEY and injects it into the server — the bundle carries both the lindris and lindris-mcp binaries, so there is nothing else to install. Generate the key in the Lindris dashboard under Account → API.

How the MCP server authenticates

lindris-mcp resolves credentials exactly like the CLI — OS keyring first, then the LINDRIS_API_KEY environment variable (see Authentication). A bundled server has no interactive auth login and no keyring entry, so in practice it authenticates from the LINDRIS_API_KEY that Claude Desktop injects.

Quote the key wherever you set it — a Lindris API key can contain a |, which an unquoted value lets the shell read as a pipe and corrupt the key.

What the tool surface withholds

lindris people list is not an MCP tool. It works in a terminal, but the server publishes no tool for it: a paginated contact read puts whole pages of email addresses and custom fields into a model's context, and that is not something an agent should inherit because your API key can reach it.

There is no way to re-enable the tool today — no config field, environment variable, build tag or flag turns it back on; the walk skips it on the annotation alone. The supported path for a bulk contact read is running lindris people list in a terminal yourself. Per-account granting is tracked as phase 1 of awesomemotive/lindris-cli#115.

Targeted lookup stays available. lindris people get <id-or-email> is a tool, and its description says plainly that the answer is personal data.

A separate rule skips the framework commands. auth, doctor, agent-context, api, profile, version, which, about, completion, feedback and help publish no tool either, because they configure or describe the CLI rather than answer about your data — not because they are withheld. So the published surface is neither the whole command tree nor the tree minus mcp:hidden.

This is a client-side boundary, not a server-side one. Anything holding your API key can still call GET /api/people directly, so treat the key itself as the thing that grants access to your contacts.

Where to next

• Claude Code / Codex — the lighter path when a terminal is available.
• Authentication — the key-resolution model the MCP server shares with the CLI.
• Browse the full command reference — every tool the MCP server exposes maps to one of these commands (the reverse does not hold; see above).