Connecting from clients

The MCP protocol is transport-agnostic — @loguro/mcp speaks stdio, which is what every mainstream MCP client expects. The same JSON config works in any client that supports the standard mcpServers shape.

Spawn-on-demand model

There is no long-running daemon. Claude Code (or your client) spawns bunx @loguro/mcp when a conversation needs it and tears the process down when the conversation ends. Each conversation gets a fresh server with a fresh token read from disk — there is nothing to manage, nothing to restart, and updates ship as soon as bunx re-fetches the package.

Claude Code

The canonical config. Add to ~/.claude/settings.json (global, applies to every conversation) or .claude/settings.json at the root of a project (per-project, only loaded when you open Claude Code in that directory):

{
  "mcpServers": {
    "loguro": {
      "command": "bunx",
      "args": ["@loguro/mcp"],
      "env": {
        "LOGURO_PROJECT": "your-project-slug"
      }
    }
  }
}

Use the per-project file when you have multiple Loguro projects and want each repo to default to its own slug. Use the global file when you only debug one app.

Other MCP clients

The MCP protocol is standard. Most editors that support MCP (Cursor, Zed, etc.) accept the same JSON shape under mcpServers — command, args, and env are part of the spec, not Claude-specific.

If your client documents an mcpServers config block, point it at the same three fields:

{
  "mcpServers": {
    "loguro": {
      "command": "bunx",
      "args": ["@loguro/mcp"],
      "env": {
        "LOGURO_PROJECT": "your-project-slug"
      }
    }
  }
}

The location of the settings file differs per client (typically ~/.cursor/... for Cursor, project-level .cursor/mcp.json, etc.) — check your client’s MCP docs for the exact path. The contents of the loguro entry stay the same.

Project vs global config

You can run both — the per-project file overrides keys defined globally, so you can set LOGURO_TOKEN once globally and override LOGURO_PROJECT per repo.