chrome-cookies-mcp
chrome-cookies-mcp
An MCP (Model Context Protocol) server that reads cookies for a specified domain from a running Chrome instance, via the Chrome DevTools Protocol (CDP).
It returns cookies already decrypted by Chrome (no SQLite decryption, no
App-Bound-Encryption handling), in cookies.txt (Netscape), JSON, or
Cookie:-header format.
How it relates to the "Get cookies.txt LOCALLY" extension
That extension uses the privileged chrome.cookies.getAll({ domain }) API,
which only works inside an extension. A standalone MCP server can't call it,
so this project gets the same decrypted cookies a different way: it attaches to
Chrome over CDP and calls Storage.getCookies, then applies the same
domain-matching and the same Netscape/JSON/header serialization the extension
used.
Related MCP server: chrome-devtools-mcp
Requirement: launch Chrome with a debug port
CDP only works against a Chrome started with --remote-debugging-port. Chrome
allows just one process per profile directory, so if your normal Chrome is
already running you must close it first, then relaunch with the flag (still
your real profile, same logins/cookies):
chrome.exe --remote-debugging-port=9222 \
--user-data-dir="C:\Users\<you>\AppData\Local\Google\Chrome\User Data" \
--profile-directory=Default \
--remote-allow-origins=*Helper:
npm run launch-chrome # close your main Chrome firstVerify the port is live: open http://127.0.0.1:9222/json/version.
Install
npm install
cp .env.example .env.local # then edit .env.local for your machineLocal configuration (.env.local)
Machine-specific settings (paths, port, profile) live in .env.local, which
is gitignored and never committed. Copy .env.example to .env.local and edit.
Values already set in the real environment — or in an MCP client's env
block — override the file, so the same code runs unchanged on any machine.
Environment variables:
Var | Default | Meaning |
|
| CDP host |
|
| CDP remote-debugging port |
| auto-detected | chrome.exe path (launcher only) |
| OS default profile dir | profile dir (launcher only) |
|
| profile name (launcher only) |
Run
npm startTools
get_cookies
Get cookies for a domain.
domain(required):"example.com",".github.com", or a full URL like"https://example.com/path".format:netscape|json|header(defaultjson).name(optional): only the cookie with this exact name.path(optional): only cookies with this exact path.
Domain matching follows chrome.cookies.getAll: the query matches a cookie
whose host equals the domain or is a sub/parent-domain of it.
list_domains
List all distinct cookie domains in the running Chrome with counts.
filter(optional): case-insensitive substring of the domain name.
Register with an MCP client
Example (claude / Claude Code .mcp.json style):
{
"mcpServers": {
"chrome-cookies": {
"command": "node",
"args": ["/absolute/path/to/chrome-cookies-mcp/src/index.mjs"],
"env": { "CHROME_CDP_PORT": "9222" }
}
}
}Test
npm run launch-chrome # or launch any Chrome with --remote-debugging-port=9333
CHROME_CDP_PORT=9333 node test/smoke.mjsSecurity note
This server exposes your browser's cookies — including session tokens — to any
MCP client connected to it. Cookies are sensitive credentials. Run it only
locally and only with clients you trust. The CDP debug port itself is also a
powerful local interface; do not expose it beyond 127.0.0.1.
Available Tools
2 toolsget_cookiesA
Get cookies for a given domain from the running Chrome (via DevTools Protocol). Returns cookies whose domain equals or is a sub/parent-domain of the query, in the requested format. Chrome must be launched with --remote-debugging-port.
Inputs: domain (required), name, path, format.
list_domainsA
List all distinct cookie domains currently present in the running Chrome, with cookie counts. Useful to discover which domains have cookies before calling get_cookies.
Inputs: filter.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: get_cookies retrieves cookies for a given domain, while list_domains enumerates available domains. There is no ambiguity or overlap.
Both tools follow a consistent verb_noun pattern in snake_case (get_cookies, list_domains), making the naming predictable and clear.
With only two tools, the set is perfectly scoped for the narrow domain of reading Chrome cookies. Each tool serves a distinct, necessary function without excess or deficiency.
For a read-only cookie retrieval tool, the combination of listing domains and fetching cookies covers the essential workflow completely. No gaps are apparent for the stated purpose.
Maintenance
Related MCP Connectors
MCP server to assist with JxBrowser development.
Experimental MCP server for current empirical verification of explicit public HTTPS endpoint claims.
Official Browserless MCP server: browser automation, scraping, screenshots and PDFs for AI agents.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides tools for interacting with Chrome through its DevTools Protocol, enabling remote control of Chrome tabs to execute JavaScript, capture screenshots, monitor network traffic, and more.96 npm52MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP Server for Chrome DevTools, following the Chrome DevTools Protocol. Integrates with Claude Desktop and Claude Code.315MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that captures browser console logs and network requests via the Chrome DevTools Protocol. It allows users to monitor real-time logs, inspect network traffic, and execute JavaScript code directly in the browser context.1MIT
- AlicenseNot gradedqualityDmaintenanceMCP server that connects to your browser to capture screenshots, inspect console logs, network requests, and more via Chrome DevTools Protocol.16 npm2MIT