Local MCP package

The @randomfact/can-mcp npm package runs a Can MCP server as a local process (stdio transport). Most people should use the hosted MCP server instead — the local package is for power users who want the full API surface or a purely local setup.

When to use the local package

• You want every API operation as a tool. The hosted server exposes a curated catalog; the local package derives its tool list from the live OpenAPI spec, so every REST endpoint — including deletes — is available, and new endpoints appear automatically.
• You use Claude Code or Claude Desktop and prefer stdio. No remote connector configuration; the server runs on your machine. In Claude Code, the Can plugin is the easier route unless you specifically want the full API surface locally.
• You point at a non-production deployment via --base-url.

Setup

Claude Code:

claude mcp add can --scope user -- npx -y @randomfact/can-mcp

Claude Desktop — add to claude_desktop_config.json:

{
  "mcpServers": {
    "Can": {
      "command": "npx",
      "args": ["-y", "@randomfact/can-mcp"]
    }
  }
}

Then restart the client. Any other MCP client that speaks stdio works the same way: point it at npx -y @randomfact/can-mcp.

Signing in

There is no login command. The first tool call opens a browser tab; sign in with your Can account once and the token is cached locally:

Platform	Token cache
Linux	~/.config/can-mcp/tokens.json
macOS	~/Library/Application Support/can-mcp/tokens.json
Windows	%APPDATA%\can-mcp\tokens.json

If a token expires mid-session the server refreshes it silently; if the refresh fails, the browser pops once more. Delete the cache file to force a fresh sign-in.

Useful flags

Flag	Purpose
--base-url <url>	Target a different Can deployment (default https://api.can.randomfact.com).
--manual-code	Headless / SSH flow: prints the sign-in URL, reads the code from stdin.
--transport http --port 3100	Expose the server over HTTP instead of stdio.
--token-store <path>	Override the token cache location.

Identity and audit

The local package authenticates with the same OAuth flow as everything else: tools act as you, with your workspace roles. Activity history entries made through it are labeled so boards can tell integration writes from in-app edits.