MCP server

Claude Code reads .claude/ directly and needs none of this. Editors that speak MCP instead — Cursor, Zed, Windsurf, VS Code's agent mode — get the same surface through this server.

npx lq-mcp

It walks up from the working directory for .lq/manifest.json and serves that project. If it does not find one it refuses to start rather than guessing, since guessing would mean serving some unrelated directory's files as if they were your conventions.

What it exposes

Resources — eighteen of them in a stock project:

Tools — two:

Two decisions worth knowing

Everything is read from your project at request time. Nothing is bundled, cached between calls or summarised. A server carrying its own copy of the conventions would be wrong the first time you edited a skill, and wrong invisibly — which is the failure the whole docs pipeline exists to prevent, and it would be silly to reintroduce it one layer up.

The practical consequence is that a skill you wrote yourself is exposed exactly like the seventeen that ship. The surface is yours, not ours.

Generation is preview-only. lq_generate_preview always passes --dry-run and there is no flag to make it write.

An agent that can write twenty files into your repository through a channel you are not watching is a different product with a different risk profile. The dry run gives an agent what it actually needs — the file list and the shape of the slice — and leaves the write in a terminal where a person can see it.

lq_check, by contrast, only reads, so it runs for real.

Configuring an editor

Point your client at the binary with the project as its working directory. For a client using the common JSON shape:

{
  "mcpServers": {
    "launch-quickly": {
      "command": "npx",
      "args": ["lq-mcp"],
      "cwd": "/path/to/your/project"
    }
  }
}

cwd matters — that is how the server finds the project, and without it you get whatever directory your editor happened to launch from.

Why the tools return raw output

lq_check returns the checker's text rather than a pass/fail verdict, because the messages are the useful part. Each one names the rule and what to do instead:

Use a colour token like text-muted-foreground rather than opacity-80. Opacity fades the text toward whatever is behind it, so it lands on a different colour in dark mode than every other muted label in the app.

An agent handed only "failed" has been given strictly less than a person reading the same terminal, which defeats the point of writing the messages that way.

A failing check comes back as content with isError set, not as a transport error — a failure is an answer, and burying it in a stack trace would hide the part that helps.