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.
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
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.
npm install
cp .env.example .env.local # then edit .env.local for your machine.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) |
npm startget_cookiesGet cookies for a domain.
domain (required): "example.com", ".github.com", or a full URL like "https://example.com/path".
format: netscape | json | header (default json).
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_domainsList all distinct cookie domains in the running Chrome with counts.
filter (optional): case-insensitive substring of the domain name.
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" }
}
}
}npm run launch-chrome # or launch any Chrome with --remote-debugging-port=9333
CHROME_CDP_PORT=9333 node test/smoke.mjsThis 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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional: only return the cookie with this exact name. | |
| path | No | Optional: only return cookies with this exact path. | |
| domain | Yes | Domain or URL to fetch cookies for, e.g. "example.com", ".github.com", or "https://example.com/path". | |
| format | No | Output format: "netscape" (cookies.txt), "json" (full cookie objects), or "header" (Cookie: header value). Default "json". | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It explains the domain matching logic (sub/parent-domain), format options, and the requirement for a specific Chrome launch mode. This provides sufficient behavioral context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and resource. No fluff, every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should detail return values. It mentions returning cookies in a format but does not describe the structure of each format (e.g., what properties in JSON, how netscape format looks). This is a significant gap for a tool with multiple output formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the domain matching behavior (sub/parent-domain) beyond the schema's simple description. It also clarifies the format options, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get cookies'), the resource ('cookies from Chrome via DevTools Protocol'), and the domain constraint. It distinguishes from sibling tool 'list_domains' by focusing on cookie retrieval for a specific domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It mentions a prerequisite (Chrome with --remote-debugging-port) but lacks guidance on when not to use it or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional substring to filter domain names (case-insensitive). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description accurately describes a read operation on the current Chrome session. Minor omission of explicit read-only status, but transparent overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that front-loads purpose and key details without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, no output schema, and no annotations, the description fully covers tool purpose, usage, and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the filter parameter. The tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all distinct cookie domains with counts, which is specific and distinguishes it from the sibling get_cookies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's useful before calling get_cookies, providing clear guidance on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_cookieslist_domainsThe 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server to assist with JxBrowser development.
Experimental MCP server for current empirical verification of explicit public HTTPS endpoint claims.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
A basic MCP server to operate on the Postman API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/k-l-lambda/chrome-cookies-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
