Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Scored, maintainable locators from a live page for AI coding agents, with checks and repairs.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Du brauchst
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein
{
"mcpServers": {
"corlabs": {
"command": "npx",
"args": [
"-y",
"@corlabsdev/mcp"
]
}
}
}Führe das in deinem Terminal aus
claude mcp add corlabs -- npx -y @corlabsdev/mcpIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"corlabs": {
"command": "npx",
"args": [
"-y",
"@corlabsdev/mcp"
]
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"corlabs": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@corlabsdev/mcp"
]
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 6. Nov. 2026
Der Herausgeber (corlabs.dev) ist nicht der Repo-Inhaber (kushshah12); vielleicht hat jemand anderes ihn eingetragen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 0 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (0.1.7) kam vor 10 Tagen in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Node.js auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, zanadir
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Find what a repository's CI is missing, and which security checks cannot fail the build.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
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.
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
claude mcp add cor -- npx -y @corlabsdev/mcp
To share it with your team, put it in .mcp.json at the project root instead:
{ "mcpServers": { "cor": { "command": "npx", "args": ["-y", "@corlabsdev/mcp"] } } }
GitHub Copilot (VS Code) — create .vscode/mcp.json (or run MCP: Add Server from the Command Palette):
{ "servers": { "cor": { "type": "stdio", "command": "npx", "args": ["-y", "@corlabsdev/mcp"] } } }
Then open Copilot Chat, switch to Agent mode, and enable cor in the tools list.
Codex (CLI and IDE extension)
codex mcp add cor -- npx -y @corlabsdev/mcp
or add this to ~/.codex/config.toml:
[mcp_servers.cor]
command = "npx" args = ["-y", "@corlabsdev/mcp"]
Cursor — .cursor/mcp.json, and Claude Desktop — claude_desktop_config.json:
{ "mcpServers": { "cor": { "command": "npx", "args": ["-y", "@corlabsdev/mcp"] } } }
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):
| Flag | Effect |
|---|---|
--headless | Run the browser without a window (default: visible) |
--idle-minutes | Close the browser after n idle minutes |
--no-records | Write no entry records into your project (see below) |
| Tool | Does |
|---|---|
cor_open | Open a page; lists its controls with refs |
cor_snapshot | Text, controls and entries within one region of a large page |
cor_inspect | Ranked, graded locators for the elements you name, as entries to place in your code |
cor_click, cor_fill, cor_press | Act on the page and report what changed |
cor_check | Fail any locator in your files that did not come from COR |
cor_grade | Score a locator you wrote yourself |
cor_heal | Propose a repair for a locator that stopped matching |
cor_close | Close the browser |
cor_open the page, then cor_inspect every element the test touches, in one call.// COR cor:… comment included, in the file it names.cor_check before the tests. When a test breaks on a locator, cor_grade it and cor_heal if it is broken.npx -y @corlabsdev/mcp runs the latest version each time it starts. To pin one, use npx -y @corlabsdev/mcp@0.1.0.
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:
module.exports = {
framework: 'playwright', // 'playwright' | 'cypress' | 'webdriverio' locators: { order: 'framework', // 'framework' (default: each framework's published guidance, after uniqueness) or 'testid-first' testIdAttribute: 'data-test', // what getByTestId reads (default: playwright.config's testIdAttribute, else data-testid) store: 'page-object-class', // 'page-object-class' | 'constants' | 'json' | 'yaml' storeDir: 'tests/pages', }, }
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/ .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:
| Found in text, attributes, classes or locators | Stored as |
|---|---|
| an email address | [email] |
| a run of 6 or more digits (order numbers, phone and card numbers; spaces and dashes allowed) | [number] |
| a long string of 24+ mixed letters and digits (tokens, session ids) | [token] |
the query string or fragment of an href | removed |
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.
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, or timeout), 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.