Skip to content

Use from a Coding Agent over MCP

lgtmaybe mcp runs a Model Context Protocol (MCP) server on stdio (standard input and output). A coding agent such as Claude Code or Cursor connects to it. The agent then reviews your local changes by calling a tool. It no longer needs to run lgtmaybe review in a shell and parse what it prints.

The review is the same one lgtmaybe review runs: the same engine, the same config files, the same credentials. Nothing is posted anywhere.

Contents

Install the MCP Extra

The MCP SDK is an optional extra, so a plain install stays small. Install it with pip. uv tool install and pipx install also work, and put lgtmaybe on your PATH in an isolated environment.

pip install 'lgtmaybe[mcp]'

The Homebrew formula and the Windows executable do not include the extra, so use pip for lgtmaybe mcp. Without the extra, the command exits with a message naming the extra to install.

Add It to Claude Code

From the repository you want reviewed, register the server with claude mcp add. Everything after -- is the command Claude Code runs. The lgtmaybe mcp flags apply to every review the agent asks for.

claude mcp add lgtmaybe -- lgtmaybe mcp \
  --provider ollama \
  --model qwen3.6:27b \
  --api-base http://localhost:11434

Claude Code starts the server in the project directory, so the review sees that repository. Add --scope project to write the entry to the repository's .mcp.json and share it with your team.

The entry stores the command and every flag exactly as you typed them. So never pass --api-key to claude mcp add or write it into .mcp.json: the key would sit in a file you commit. Supply API keys through environment variables instead (see Credentials and Config).

Then ask the agent for a review in plain words, for example:

Review my uncommitted changes with lgtmaybe and fix anything high severity.

Add It to Another MCP Client

Most clients (Cursor, Windsurf, Claude Desktop and others) read an mcpServers block from a JSON config file. Add an entry that runs lgtmaybe mcp. Pass -C with the repository path when the client does not start servers inside your project.

{
  "mcpServers": {
    "lgtmaybe": {
      "command": "lgtmaybe",
      "args": [
        "mcp",
        "--provider", "openai",
        "--model", "gpt-5.5",
        "-C", "/path/to/your/repo"
      ]
    }
  }
}

If the client cannot find lgtmaybe, give the full path to the executable (which lgtmaybe prints it) as command.

The Tools

The server offers two tools. Both take the same optional arguments and run one full review per call.

Tool Returns
review_changes The findings as JSON, in the same shape as lgtmaybe review --format json, plus the summary line and incomplete (true when some review calls did not finish, so the findings may be partial).
review_instructions The findings as plain-text correction instructions, the same text as lgtmaybe review --format agent except for the closing line, which tells the agent to call the review_instructions tool again (not to run lgtmaybe review) to confirm its fixes.
Argument Meaning
mode branch (default): committed branch changes against the base. working: branch commits plus uncommitted edits. uncommitted: only the uncommitted edits against HEAD.
base The base ref to diff against, like --base. Defaults to the remote's primary branch.
min_severity Drop findings below info, low, medium, high or critical.
preset fast (five model calls, plus a sixth when a committed spec matches) or full (one call per review category).

The preset argument picks a preset: the set of lenses a review runs.

Some reviews cannot run. Examples are a folder that is not a Git repository, a missing credential, or a provider error. The review then comes back as a tool error with the reason, so the agent sees what went wrong rather than an empty result. The server keeps running for the next call.

Reviews run one at a time. A review makes several model calls, so it takes as long as lgtmaybe review does. Ask for one per change set rather than after every edit.

Credentials and Config

Config loads exactly as it does for lgtmaybe review, in this order:

  1. your user config (lgtmaybe config);
  2. the repository's .lgtmaybe.yml;
  3. the flags on lgtmaybe mcp;
  4. the tool call's own arguments.

The server reads the config files on every call, so an edit to .lgtmaybe.yml applies without restarting it. A config file that does not parse stops the server at startup, where the client shows the error.

API keys come from the environment, as they do for the CLI (OPENAI_API_KEY, ANTHROPIC_API_KEY and so on; see the provider how-tos). The server inherits the environment the client starts it with. So export the key in the shell you start the client from.

Some clients start servers without your shell environment. Then set the key in the entry's env block instead. Keep in mind that this stores it in the client's config file. lgtmaybe itself never writes a key to disk.

Keyless providers need no key at all: ollama, and Bedrock, Vertex or Azure with ambient cloud credentials.

To review with a ChatGPT subscription, run lgtmaybe login chatgpt before you start the client. The server never asks you to sign in itself, because that prompt would break the client's connection. See Review with a ChatGPT Subscription.

Troubleshooting

  • The client says the server failed to start. Run the same command in a terminal. A missing extra or a broken config prints its reason and exits. Otherwise the command waits silently for a client, which means it works.
  • The tool error says it is not a Git repository. The server started outside your project. Add -C /path/to/your/repo to its arguments.
  • Where are the logs? On stderr, which the client usually records in its MCP log. stdout carries only the protocol, so nothing lgtmaybe logs can corrupt it.

See Also