
Corlabs
dev.corlabsPublished by corlabs.devv0.1.7Updated Oct 29, 2026
Scored, maintainable locators from a live page for AI coding agents, with checks and repairs.
Overview
Local MCP server that opens a page in a browser and returns ranked, graded test locators for elements, with checks and repairs.
- What you can do
- Open a page and list its controls, or snapshot one region of a large page
- Get ranked, graded locators for named elements as entries to place in locator files
- Click, fill and press on the page and report what changed
- Check locators in your files against COR's ids, grade a locator you wrote, and propose repairs for broken ones
- Close the browser when finished
- When to use it
- Useful when a coding agent writes or maintains UI tests in Playwright, Cypress or WebdriverIO and needs stable selectors taken from a live page, plus a way to check and repair them later.
- Requirements
- Runs locally via npx, so Node 18+ is needed, plus Google Chrome, Microsoft Edge or Playwright's Chromium. No account, API key or environment variable is declared. Optional flags include --headless, --idle-minutes, --no-records, and an optional cor.config.js at the project root.
Installation
In SourceWeft
- Open Corlabs in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
@corlabsdev/mcp
An MCP server that lets a coding agent open a page, pick an element, and get ranked, graded locators for it in the test framework you use.
More at corlabs.dev.
Install
Requires Node 18+ and Google Chrome (Microsoft Edge, or Playwright's Chromium, also work). Nothing is installed globally: your agent runs the server with npx.
Add COR to your client. Every client runs the same command, npx -y @corlabsdev/mcp.
Claude Code
To share it with your team, put it in .mcp.json at the project root instead:
GitHub Copilot (VS Code) — create .vscode/mcp.json (or run MCP: Add Server from the Command Palette):
Then open Copilot Chat, switch to Agent mode, and enable cor in the tools list.
Codex (CLI and IDE extension)
or add this to ~/.codex/config.toml:
Cursor — .cursor/mcp.json, and Claude Desktop — claude_desktop_config.json:
Any other MCP client: register a stdio server whose command is npx with arguments -y @corlabsdev/mcp.
Restart the client (or reload the window), then ask your agent to open your page: "Use COR to open https://example.com/login and write the locators for the sign-in form."
If no browser is found the server says so; install Chrome, or run npx playwright-core install chromium.
Options (append to args, or after -- in claude mcp add):
Tools
Workflow
cor_openthe page, thencor_inspectevery element the test touches, in one call.- Place each entry as given, its
// COR cor:…comment included, in the file it names. - Run
cor_checkbefore the tests. When a test breaks on a locator,cor_gradeit andcor_healif it is broken.
Updating
npx -y @corlabsdev/mcp runs the latest version each time it starts. To pin one, use npx -y @corlabsdev/[email protected].
Setup: COR as the only browser tool
Configure COR MCP instead of Playwright MCP for test authoring, not alongside it: COR drives the browser (open, click, fill, press), returns locators as entries for your locator files, checks them (cor_check) and repairs them (cor_heal). With a second browser server attached, an agent falls back to its snapshots and types its own selectors — which cor_check will then fail.
Settings are optional. COR infers your test framework and conventions from the repo; to override them, add a cor.config.js at the project root. framework names the test framework and the rest go under locators. Every field is optional; cor_open reports what was inferred and what was overridden:
Entry records: what is written inside your project
Every cor_inspect that recommends a locator also gives it an entry: the code to place in your locator file, the file and member it belongs in, and a comment carrying a short id, // COR cor:7f3a2c · … (in a YAML map, # COR cor:…). Keep that comment: cor_check uses the id to tell COR's locators from typed ones, and a later repair uses it to find what the locator pointed at. COR never edits your files — the agent places the entry.
Where: .cor/records/<id>.json in your project root (where your test framework's package.json is), one small file per element. Inspecting the same element again reuses its id and refreshes its file. For a JSON locator map, which cannot hold comments, COR also keeps .cor/ids.json ("file#key": "id") — it never adds keys to your map.
Commit them. They are how a repair works on a teammate's machine or in a CI checkout: the id travels in your code and the record travels with the repo. Add .cor/records/ to .gitignore if you would rather keep them on one machine.
What each record holds: the page (origin and path, masked), the element's position as a tag path, the entry's member name, the element's fingerprint — its tag; aria-label, aria-labelledby, name, placeholder, type, role, title, alt, href, for if present; up to 80 characters of its own text; its first five class names — and up to 12 locators ranked for it, stored as data ({ "kind": "testId", "value": "[data-test=\"…\"]" }), not as code to paste. COR never shows a record's contents to the agent.
What is never stored: what anyone typed into a field (input values), cookies, local storage, or anything from a storage-state file you pass to cor_open.
Masking. On an authenticated page the fields above can contain account data, so before anything is written:
Short numbers and ordinary words are kept, because a heal needs them ("Step 2", "Qty 12", "Pay now"). Values are masked, not hashed. A heal compares stored values with the live page as plain text, so a hashed value could never match again.
Turning it off: start the server with --no-records or set COR_RECORDS=off (the old --no-fingerprints / COR_FINGERPRINTS=off still work): no record is written; entries still carry an id, and cor_check then checks ids for presence only. The ~/.cor/fingerprints/ store of earlier versions is no longer written or read; deleting it is safe.
Telemetry: anonymous usage metrics
The server sends anonymous usage metrics to help us see how COR is installed and used. Two events:
mcp_installed, once per install, on the first start: package version, Node version, OS platform.mcp_tool_called, once per tool call: tool name, duration in milliseconds, outcome (ok,tool_error,exception, ortimeout), package version.
Each install has a random anonymous ID, stored in ~/.cor/install-id. The first start prints one line on stderr saying so.
Never sent: page URLs or origins, element text, locators, file paths, input values, cookies, storage, record contents, error messages, or any email address. Every field is listed in the code (src/telemetry.js), and nothing else is added.
Turning it off: set COR_TELEMETRY=off (or COR_OFFLINE=true, which stops all outbound data). Nothing is sent and no ID file is written.
Source: README.md at commit 2d6b750
Tools
0Version history
1- v0.1.7LatestOct 29, 2026
Score
40% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts
Declare a license in the repository or the registry entry.