Connect it
In the console, open Settings, then Coding tools, and press Create token. The console asks what the token is for (My laptop, say), then shows the whole command with your token already in it, once: only a fingerprint of the token is stored, so nobody can read it back later. If you lose it, revoke it in the same place and create another.
Claude Code
claude mcp add --transport http nth-labs https://console.nthlabs.dev/mcp \
--header "Authorization: Bearer nthl_YOUR_TOKEN"
Paste the command the console gives you; it carries your token where this one says nthl_YOUR_TOKEN.
Cursor
The same address and header, in .cursor/mcp.json (or ~/.cursor/mcp.json):
{ "mcpServers": { "nth-labs": {
"url": "https://console.nthlabs.dev/mcp",
"headers": { "Authorization": "Bearer ${env:NTH_LABS_TOKEN}" } } } }
The token is read from an environment variable (NTH_LABS_TOKEN here) rather than stored in a file you might commit.
Codex
In ~/.codex/config.toml, reading the token from the same variable:
[mcp_servers.nth-labs]
url = "https://console.nthlabs.dev/mcp"
bearer_token_env_var = "NTH_LABS_TOKEN"
Claude, in the app or on claude.ai
Add nth Labs as a custom connector with the address https://console.nthlabs.dev/mcp. Claude opens an nth Labs page that asks whether to connect; press Connect. There is no token to copy, and the connection can be revoked from Coding tools like any token.
Any other MCP client takes the same address and header. A client that only speaks stdio can bridge to it with mcp-remote.
Runs your coding tool starts happen on the console, under the same limits as the Run button. They can test any address the console can reach, but not a localhost port on your machine. For a product that is not deployed yet, run nth Labs yourself.
What to ask it
You do not need to learn the tools. Ask in plain words, and your coding tool picks the call:
| You ask | The tool it calls |
|---|---|
| Where do things stand? | labs_status |
| What should I fix? | labs_findings, then labs_fix_prompt for one of them |
| Fix everything. | labs_fix_prompt with all: true |
| Is it fixed? | labs_verify with the finding’s id |
| Find bugs for free. | labs_check |
| Will it sell? | labs_validate, then labs_lab for the revenue band |
| What changed? | labs_brain for changes since a date, then labs_trend |
| Brief me before I work on it. | labs_brain_context |
| Check this page says X. | labs_expect, with arm: true to keep it true |
| Keep it from breaking again. | labs_guard |
| Judge the design yourself. | labs_review, then labs_file_findings |
| Is my run done? | labs_run |
A long run answers within about fifteen seconds: with the whole result if it is that quick, or with a run id to follow through labs_run if not. One run goes at a time per account, and a run waiting in the console’s queue counts as that one: ask for a second and the answer says what is holding the slot. When the console is at capacity, a run your coding tool asks for is turned away with when to try again, while one pressed in the console waits its turn and starts on its own.
When you ask what to fix, a connected tool gets back the open findings, worst first, each with its id:
> labs_findings { limit: 5 }
5 distinct defects shown, of 30 open occurrences across 23 defects; what costs the business first: money (a way to pay, a price), then lost work, then a blocked main path, then trust and security; polish after (accessibility markup, metadata, headers and speed scores never lead) and suggestions last. Inside each: reproduced on video first, then what a browser proved, then the front page and main flow before deep pages, then severity and the Lab's order:
-- loses money: someone ready to pay cannot, or is charged the wrong amount --
[Loses money] [094d09] A secret key is visible in your website's code (landing) 65% confidence
on 3 pages (landing, pricing, login): one shared cause, fix it once
-- loses their work: what a customer typed or saved is gone, and so is their trust --
[Loses their work] [8fd766] The save says it saved, and it did not (settings) 65% confidence
-- blocks the main path: a customer cannot get through the thing they came to do --
[Blocks the main path] [4f29b3] "Billing and invoices" on /app/settings opens a page that does not exist (404) (settings) 98% confidence
…
What it costs
On console.nthlabs.dev your plan decides what a coding tool may do:
- Every plan: read status, findings, fix prompts, the Readiness report, the Lab and the Brain.
- Pro and above: run checks and change things too, such as verifying a fix, filing a finding or writing a note.
Of the checks it can run, the browser checks use none of your plan’s validations: labs_check, labs_guard, labs_review, labs_assist, labs_trips, labs_explore, labs_elements, labs_expect and labs_compare. The ones that call a model use your plan’s validations: labs_audit, labs_wander, labs_gate, labs_walk, labs_ask_person, labs_react, labs_crowd and labs_strategy. labs_verify depends on the finding: the browser settles it when the steps can be repeated, and a model looks when they cannot.
labs_status says which tools are free and which use your plan, before you run anything. A run that called a model, such as labs_audit or labs_wander, says in its answer how many model calls it used from your plan.
Why a browser checks each fix
Your coding tool makes a change, a real browser checks whether it worked, and the tool reads the result. Without the browser, nothing confirms a coding tool’s report that a fix worked.
Running it yourself
From a copy of the repository, the same tools run over stdio on your own machine, and can test localhost:
claude mcp add nth-labs -- node /ABSOLUTE/PATH/TO/nthlabs/cli.cjs mcp
That command is for Claude Code. Any other client starts the same server with node cli.cjs mcp. The free tools need nothing more. The ones that call a model need an API key for the model you run, set in your MCP config; see AI and your plan.
The console publishes a plain-text guide at console.nthlabs.dev/llms.txt: what nth Labs is, how to connect, the fix loop, and which tools are free and which use your plan. No token needed.