This server provides a unified MCP interface for managing browser authentication and debugging CloakBrowser sessions. It captures authentication state (cookies, localStorage) from a paired Chrome extension and injects it into Cloak profiles, while also exposing CDP-based debug sessions. Raw secrets are never exposed.
Authentication Management:
auth_list_sites: List registered auth sources, extension connection status, and allowed Cloak targets.
auth_sync_to_cloak: Capture and import auth state from Chrome to a Cloak profile (supports merge or replace).
auth_verify_cloak: Check if a profile is logged in to a site.
auth_clear_cloak: Clear auth state from a profile (requires explicit confirmation).
CloakBrowser Debug Sessions:
cloak_debug_open: Launch a headed CloakBrowser session with optional URLs, attached to CDP (default port 9333).
cloak_debug_tab: Open additional tabs in the active session without starting a new browser.
cloak_debug_list: List open tabs in the active session.
cloak_debug_status: Check if a debug session is active.
cloak_debug_close: Close the session and release the browser seat.
These tools enable a complete workflow: sync auth → open debug session → navigate, inspect network requests, scripts, breakpoints, and evaluate JS, all within one MCP server. The WebSocket bridge only binds to 127.0.0.1, and site scope is constrained by local config files.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cloak-auth-bridge sync YouTube login to Cloak profile"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
一个本地认证与调试桥：Chrome MV3 扩展在配对后，按本地登记的站点配置采集 Cookies 和 localStorage，通过独立的本机认证服务注入 CloakBrowser 持久 Profile。
日常只装 MCP。IDE 启动时若 127.0.0.1:17321 空闲，MCP 自己带上扩展认证桥；已被占用则复用已有实例。
Cloak 窗口活在这个 MCP 进程里：关掉 IDE / 重载 MCP，窗口一起关。
serve 是可选项：只在希望 IDE 关掉后扩展仍保持连接时才单独常驻。
扩展安装时默认具备 https://*/* 读取权限，不再要求逐站点“授权并加入白名单”。真正的站点范围由 sites/ 与 profiles.json 双重约束。MCP 工具只返回数量和验证结果，原始 Cookie/Token 不进入 LLM 上下文。
仓库：
https://github.com/inorilzy/cloak-browser-auth
codex mcp add cloak-browser-auth -- uvx --from git+https://github.com/inorilzy/cloak-browser-auth.git cloak-browser-auth-mcp或写入 ~/.codex/config.toml：
[mcp_servers.cloak-browser-auth]
command = "uvx"
args = [
"--from",
"git+https://github.com/inorilzy/cloak-browser-auth.git",
"cloak-browser-auth-mcp"
]
startup_timeout_sec = 60
tool_timeout_sec = 180
enabled = true换电脑：加上这条 MCP 即可。第一次启动会播种 ~/.cloak-browser-auth/，并在 :17321 空闲时自己打开认证桥。不必再另开终端跑 serve。
uvx 会从 GitHub 拉取包。首次运行会在用户目录播种配置：
~/.cloak-browser-auth/
sites/
profiles.json
extension/ # 给 Chrome 加载
profiles/ # Cloak 持久登录态
.auth/也可用环境变量指定数据目录：
$env:CLOAK_BROWSER_AUTH_HOME = "D:\cloak-auth-data"git clone https://github.com/inorilzy/cloak-browser-auth.git
cd cloak-browser-auth
.\scripts\setup.ps1本地 Codex 可直接使用仓库内 .mcp.json。Cursor 用 .cursor/mcp.json。两者都只写 mcp 这一条命令。
{
"mcpServers": {
"cloak-browser-auth": {
"command": ".venv/Scripts/python.exe",
"args": ["-m", "cloak_browser_auth", "mcp"]
}
}
}第一个 MCP 进程占用 17321 并接待 Chrome 扩展；第二个 IDE 再开 MCP 时自动连上已有桥。默认复用本机 DPAPI secret；需要覆盖时两端设相同的 CLOAK_BROWSER_AUTH_CLIENT_TOKEN。
Related MCP server: chrome-agent-bridge
换机 / 日常：只启动 MCP。
.\.venv\Scripts\python.exe -m cloak_browser_auth mcp成功后：
扩展连 ws://127.0.0.1:17321（由这个 MCP 或已有实例提供）
Agent 可直接调下方工具
重载 MCP 会关闭 Cloak 窗口
:17321 只允许一个认证桥；后启动的 MCP 自动复用
可选：希望 IDE 全关后扩展仍在线，再单独跑 serve。
默认 本机 loopback trust：扩展只要连 ws://127.0.0.1:17321，无需粘贴 Token。
在 IDE 里启用 cloak-browser-auth MCP（它会打开 17321）
Chrome 加载 extension/ 并打开弹窗
Token 留空，点「保存并重连」
顶部显示「已连接」即可
可选加固：设置环境变量 CLOAK_BROWSER_AUTH_REQUIRE_TOKEN=1 后，再用 .\scripts\pair.ps1 复制 Token 粘贴到扩展。Token 不要发给 LLM。
IDE 启动 cloak-browser-auth MCP（空闲则自带 :17321）
-> Chrome 扩展连 ws://127.0.0.1:17321
-> auth_sync_to_cloak
-> cloak_debug_open（本进程打开 Cloak）
-> 调试：navigate_page / list_network_requests / ...
-> MCP 退出，窗口一起关auth_list_sites — 站点列表 + 扩展是否已连接
auth_sync_to_cloak — 从 Chrome 扩展采集并导入 Cloak（mode=merge|replace）
auth_verify_cloak — 验证 Profile 登录态
auth_clear_cloak — 清理（必须 confirm=true）
cloak_debug_open — 在本 MCP 进程启动或复用 headed CloakBrowser（默认 shared-main）
cloak_debug_tab / cloak_debug_list / cloak_debug_status / cloak_debug_close(profile_id, confirm=true)
cloak_reap_stale — 列出或杀掉占着 Free 席位的残留 Cloak 进程（不动 Google Chrome；杀掉要 confirm=true）
会话：
reverse_attach / reverse_detach / reverse_status
页面与导航：
select_page / new_page / navigate_page / select_frame / click_element / take_screenshot
脚本分析：
list_scripts / get_script_source / save_script_source / search_in_sources
断点与执行：
set_breakpoint_on_text / break_on_xhr / remove_breakpoint / list_breakpoints
get_paused_info / pause_or_resume / step
网络与 WebSocket：
list_network_requests / clear_network_requests / get_request_initiator / get_websocket_messages
状态与检查：
list_console_messages / evaluate_script / clear_site_data
这些工具操作 cloak_debug_open 在本进程打开的同一 Cloak 窗口。MCP 退出时窗口一起关。
统一工作流：
auth_sync_to_cloak(site, profile)
cloak_debug_open(profile, urls=[...])
list_network_requests / search_in_sources / evaluate_script / ...
cloak_debug_close(profile, confirm=true)同步示例：
{
"name": "auth_sync_to_cloak",
"arguments": {
"site_id": "xiaohongshu-main",
"target_profile": "shared-main",
"mode": "merge"
}
}打开 Cloak：
{"name": "cloak_debug_open", "arguments": {"profile_id": "shared-main", "url": ["https://www.xiaohongshu.com"]}}
{"name": "cloak_debug_status", "arguments": {}}
{"name": "cloak_debug_close", "arguments": {"profile_id": "shared-main", "confirm": true}}站点范围只在本地配置文件维护，扩展弹窗不再登记站点。
sites/bilibili.json -> bilibili-main
sites/x.json -> x-main
sites/youtube.json -> youtube-main
profiles.json
bilibili-main / x-main / youtube-main (dedicated)
shared-main (多站调试共用)新增站点：在 sites/ 增加 JSON，并在 profiles.json 映射允许的 Profile；多站联调把 site id 加进 shared-main.allowedSites。
第一次真正同步时，cloakbrowser 可能下载 Chromium 二进制。Profile 默认有头可开；注入后通过站点 verify 检查登录状态。
Chrome 扩展
│ WebSocket 127.0.0.1:17321
▼
MCP stdio
├─ 认证桥（:17321 空闲则嵌入，否则复用）
└─ cloak_debug_open → 本进程 launch CloakBrowser → profiles/
可选：单独 serve 常驻同一端口，给无 IDE 场景用（不管浏览器）关掉 MCP 会关 Cloak 窗口。也可以 cloak_debug_close(profile_id=..., confirm=true) 或手动关窗。
Chrome 打开 chrome://extensions，启用“开发者模式”。
“加载已解压的扩展程序”，选择本仓库 extension 目录，或用户目录里播种的 ~/.cloak-browser-auth/extension。
在 IDE 里启用 MCP（它会打开 17321），扩展弹窗 Token 留空，点「保存并重连」。
只有启用了 CLOAK_BROWSER_AUTH_REQUIRE_TOKEN=1 时，才需要 .\scripts\pair.ps1 粘贴 Token。
扩展默认申请 https://*/*，只支持 HTTPS，只允许连接 ws://127.0.0.1。
连接后扩展先发 challenge；服务端回 hello_challenge；扩展回 hello_response；服务端 hello_ack 后可采集。
完成认证后服务端按注册表请求：
{
"id": "0192f0cb-1234",
"type": "capture_auth",
"site_id": "example-main",
"cookie_domains": ["example.com"],
"origins": ["https://www.example.com"],
"nonce": "at-least-16-random-url-safe-characters"
}扩展校验范围后采集并返回 capture_auth_result。payload 仅允许服务端内存消费，禁止进日志 / MCP result / LLM。
.\.venv\Scripts\python.exe -m cloak_browser_auth doctor
.\.venv\Scripts\python.exe -m pytest -q
npm testToken：.auth/pairing-token.dpapi，只经 pair.ps1 进剪贴板
Cookie/localStorage：仅在本机扩展、认证服务与同步流程内存中流转，不落日志、不进工具返回
WebSocket：只绑 127.0.0.1
站点范围：daemon 注册表为第二道白名单
Free Cloak：同时 1 个 browser；多站用 shared-main + 多 tab
npm test
Get-ChildItem extension -Filter *.js | ForEach-Object { node --check $_.FullName }extension/ 可直接被 Chrome 以未打包扩展加载。
Clear one registered site's authentication state from a Cloak profile. Requires confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | ||
| site_id | Yes | ||
| target_profile | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the operation clears auth state and requires confirmation (confirm=true), which implies a destructive, safety-gated action. However, it does not mention reversibility, side effects, or permissions, leaving some gaps.
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?
The description is one sentence plus a short requirement note. It is front-loaded with the action and contains no wasted words, earning full marks for conciseness.
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?
The tool has three required parameters, no annotations, and no output schema, yet the description provides only minimal context. It does not explain the effect of 'confirm', potential consequences, or how it fits with sibling tools, leaving the agent with an incomplete picture.
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 description coverage is 0%, and the description does not explain the parameters directly. It vaguely mentions 'site' and 'profile' but does not map site_id, target_profile, or confirm to their roles or formats. The parameter names are somewhat self-explanatory, but the description adds little value beyond that.
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 ('Clear'), the resource ('authentication state'), and the scope ('one registered site' from a 'Cloak profile'). It distinguishes this from sibling tools like auth_list_sites (listing), auth_sync_to_cloak (syncing), and auth_verify_cloak (verifying).
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 implies when to use the tool (when clearing a site's auth state from a Cloak profile) but does not explicitly state when not to use it or mention alternatives among sibling tools. The 'Requires confirm=true' note gives a prerequisite but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List registered Chrome authentication sources, whether the extension bridge is connected, and each site's allowed Cloak targets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral transparency. The verb 'List' implies a read-only operation, and the description adds useful context about what is reported (bridge connection, allowed targets). However, it does not explicitly state that it is safe/non-mutating or describe potential side effects like checking the extension connection.
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?
The description is a single, efficient sentence that front-loads the main action ('List') and then provides the key output scopes. No wasted words, and it is easy to parse.
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?
For a zero-parameter list tool with no output schema, the description covers the main return contents (auth sources, bridge status, allowed Cloak targets). It is slightly ambiguous about the relationship between 'sources' and 'sites,' but overall it provides sufficient context for an agent to understand the tool's purpose and expected output.
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?
This tool has zero parameters, so the baseline is 4. The description adds meaning beyond the empty schema by explaining what the list operation returns, though there are no parameter details to clarify.
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 uses the specific verb 'List' and clearly identifies the resource: 'registered Chrome authentication sources,' plus the additional scopes of bridge connection status and allowed Cloak targets. This distinguishes it from sibling operations like auth_sync_to_cloak or cloak_debug_list.
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 states what the tool does but provides no guidance on when to use it versus alternatives. It doesn't mention exclusions, prerequisites, or any sibling tools, so the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture an allowlisted login state from the connected Chrome extension and import it into an allowlisted Cloak profile. Raw authentication secrets are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | merge | |
| site_id | Yes | ||
| target_profile | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It usefully states 'Raw authentication secrets are never returned,' but omits critical mutation semantics such as whether the target profile is overwritten, how merge/replace affects existing state, or any allowlist requirements. As a mutating operation, this is a significant gap.
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?
The description is compact, two sentences long, with no filler. The first sentence states the operation, and the second adds a key security guarantee. Every word earns its place.
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 three parameters, one enum, no output schema, and no annotations, the description is too brief to be complete. It lacks explanation of mode semantics, prerequisites like allowlisting, what the extension connection requires, and any return or error behavior. The statement about never returning secrets hints at output but does not cover tool operation details.
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 description coverage is 0%, so the description must compensate. It implicitly maps 'login state' to site_id and 'Cloak profile' to target_profile, but the mode parameter (merge/replace) is completely unexplained. The description adds minimal beyond the raw parameter names.
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 specific action: 'Capture an allowlisted login state from the connected Chrome extension and import it into an allowlisted Cloak profile.' It identifies both the source and destination resources, making it distinct from siblings like auth_list_sites, auth_verify_cloak, and auth_clear_cloak.
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 conveys the core use case but does not explicitly state when to use this tool versus alternatives or provide exclusions. It implies usage for syncing authentication state but stops short of naming sibling tools or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify whether an allowlisted Cloak profile is logged in to a registered site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | ||
| target_profile | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. While 'verify' suggests a read-only operation, the description does not explicitly state that it makes no modifications, what it returns (e.g., boolean), or whether it has side effects like network calls or caching. This leaves the agent uncertain about the tool's behavior beyond the basic action.
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?
The description is a single sentence of twelve words, front-loading the key verb and resource. Every word contributes to meaning, with no filler or repetition. It is maximally concise while remaining informative.
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?
For a tool with no output schema and no annotations, the description must compensate by explaining the return value or behavioral details. It does not mention what outcome the tool reports (e.g., 'true' or 'false'), nor any conditions that might affect the result. The description is complete for stating the tool's existence but incomplete for an agent to fully understand the output or preconditions.
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?
The input schema has two parameters with zero description coverage, so the description's job is to add meaning. It provides context that site_id refers to a 'registered site' and target_profile to an 'allowlisted Cloak profile', which helps map the parameters conceptually. However, it does not specify format, validation rules, or how the values are used beyond this general mapping.
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 uses a specific verb 'Verify' and clearly states the resource being checked: whether an allowlisted Cloak profile is logged in to a registered site. This distinguishes the tool from siblings like auth_list_sites (which lists sites) and auth_sync_to_cloak (which syncs). The purpose is unambiguous.
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 implies a clear use case—checking login status for a profile and site—but does not explicitly state when to prefer this tool over alternatives or any exclusions. It is sufficient for a straightforward verification, but lacks guidance on edge cases or prerequisites (e.g., profile must be allowlisted, site must be registered).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the active Cloak debug session and release the Free-plan browser seat.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool closes a session and releases a seat, which are the key behavioral effects. However, it doesn't disclose potential consequences like losing unsaved debug data, error conditions, or whether it's idempotent. This is a limitation but acceptable for a simple close 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?
The description is a single sentence that front-loads the action and includes a relevant side effect. No wasted words; it earns its place.
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?
For a zero-parameter, no-output-schema tool with no annotations, the description provides the essential purpose and a key side effect. It could mention behavior when no session is active, but the simplicity of the tool makes this adequate.
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?
Since the tool has zero parameters and the schema already covers all fields (vacuously), the description doesn't need to add parameter semantics. The baseline for zero-param tools is 4, and nothing reduces that.
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 uses a specific verb ('Close') and resource ('active Cloak debug session'), clearly distinguishing it from siblings like cloak_debug_open or cloak_debug_status. It also mentions the additional effect of releasing the Free-plan browser seat, adding precision.
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 clearly implies when to use this tool—when an active Cloak debug session needs to be closed. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for a simple close operation. It also notes the seat release, helping the agent understand why this action is important.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List page tabs in the active Cloak debug session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action and object, but does not disclose whether a session must be open, what the return format looks like, or any side effects.
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?
The description is a single, tightly worded sentence that leads with the verb and object. There is no superfluous content.
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?
For a simple list operation with no parameters and no output schema, the description is minimally adequate. However, it lacks information about the return value, session requirements, and edge cases (e.g., no active session), leaving room for improvement.
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?
The tool has zero parameters, so the baseline for this dimension is 4. The description adds context about the 'active Cloak debug session', which is relevant but not parameter-related.
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 ('List') and the resource ('page tabs') within a specific scope ('active Cloak debug session'). This distinguishes it from sibling tools like cloak_debug_status, cloak_debug_open, and cloak_debug_close.
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?
No guidance is provided on when to use this tool versus alternatives like cloak_debug_tab or cloak_debug_status. There is no mention of prerequisites (e.g., an active session) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open one headed CloakBrowser debug session for an allowlisted profile. Uses a single Free-plan browser session; open more sites with cloak_debug_tab.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional HTTPS URLs to open as initial tabs. | |
| port | No | ||
| profile_id | No | shared-main |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the session is headed, requires an allowlisted profile, and uses a Free-plan browser session. However, it omits side effects, error behavior, or authorization requirements, leaving the agent uncertain about prerequisites and potential failures.
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?
The description is two sentences, front-loaded with the purpose and immediately followed by a key limitation and alternative. Every word contributes meaningful information without redundancy.
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?
The tool has no output schema and no annotations, so the description must explain return values and operational context. It does not mention what the session returns (e.g., URL, ID), how to close it, or the need for prior authentication. The context is incomplete for an agent to invoke and use the tool effectively.
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 description coverage is only 33% (only 'url' is described). The description does not mention 'port' or 'profile_id' at all, nor does it elaborate on the 'url' behavior beyond the schema. Since the description fails to compensate for the low schema coverage, parameter semantics remain unclear.
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 'Open one headed CloakBrowser debug session' with a specific resource (debug session) and scope ('for an allowlisted profile'). It differentiates from sibling tools by noting 'Uses a single Free-plan browser session' and explicitly pointing to cloak_debug_tab for opening more sites.
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 gives clear usage context: it opens a single Free-plan session and directs the agent to use cloak_debug_tab for additional sites. However, it does not explicitly state when to avoid this tool or mention prerequisites like authentication, relying on sibling names to imply the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show whether a Cloak debug session is active.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the purpose. It does not describe the return format, side effects (or lack thereof), or what 'active' means. This is minimal info for a status check.
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?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and effectively communicates the core purpose.
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?
For a zero-parameter tool with no output schema, the description is minimally adequate. It tells the agent the tool checks status but leaves ambiguity about the exact output format or criteria for an active session. Given the low complexity, this is a reasonable score.
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?
The tool has zero parameters, so there are no parameter semantics to convey. Per the baseline for 0-parameter tools, a score of 4 is appropriate since the description does anything needed.
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's function with a specific verb 'Show' and identifies the resource as 'Cloak debug session'. It distinguishes itself from sibling tools like open/close/tab/list by focusing on status.
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?
No guidance is provided about when to use this tool versus alternatives. It does not mention whether it should precede other actions, nor does it exclude any scenarios. The usage context is entirely implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open another HTTPS tab in the active Cloak debug session via local CDP attach. Does not start a second browser process.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the CDP attach mechanism and clarifies that no second browser process is started. However, it does not describe prerequisites (e.g., active session), error behavior, or potential side effects beyond opening a tab.
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?
The description is two short sentences, front-loaded with the core action and a clarifying caveat. No redundant 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?
For a simple tool with one parameter and no output schema, the description covers the purpose, mechanism, and a key behavioral nuance. It could be more explicit about prerequisites or error cases, but it is reasonably complete given the tool's low complexity.
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 0%, so the description must compensate. It implies the url parameter is the address to open, and the 'HTTPS' qualifier suggests a constraint, but it does not explicitly describe the parameter's format, allowed schemes, or required conditions.
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 (open another HTTPS tab), the target context (active Cloak debug session), and the method (local CDP attach). It also distinguishes from siblings by noting it does not start a second browser process, clarifying its role relative to cloak_debug_open.
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 implies the tool is used within an active Cloak debug session, giving some context for when to use it. However, it does not explicitly mention alternatives or exclusions, and the note about not starting a second browser process only hints at a distinction without naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools cleanly separate into auth management (list_sites, sync, verify, clear) and debug session management (open, tab, list, status, close). Each tool has a distinct resource and action with no meaningful overlap or ambiguity.
Consistent use of prefixes (auth_, cloak_debug_) helps grouping, but the verb/noun pattern is mixed: most use verb_noun (cloak_debug_open, auth_verify_cloak), while a few use bare nouns (cloak_debug_status, cloak_debug_tab). The inconsistency is noticeable but not chaotic.
Nine tools is well-scoped for an auth bridge with debug capabilities. Each tool addresses a specific workflow step, and there are no redundant or filler tools.
Covers the core lifecycle for auth sync (list, sync, verify, clear) and debug session management (open, tab, list, status, close). Minor gaps remain, such as no explicit site removal or screenshot capability, but agents can achieve main workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Experimental MCP server for current empirical verification of explicit public HTTPS endpoint claims.
MCP server to assist with JxBrowser development.
Hosted AgentLux MCP server for marketplace, identity, creator, services, and social flows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/inorilzy/cloak-browser-auth'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
