Provides 26 browser-based operations for Reddit through the user's logged-in browser session: reads account info, home/recommended feeds, post and community search, community profiles and rules, community posts, post details, comment trees with continuation, user profiles and content, saved items, and the legacy message inbox. Also supports interactions such as upvote/downvote/retract, save/unsave, comment and reply, submit text or link posts, edit/delete one's own posts and comments, join/leave communities, send messages, hide/unhide posts, mark messages read, and unblock users.
Provides 28 browser-based operations for Zhihu through the user's logged-in browser session: reads account info, recommendation/following/hot lists, search, topic details with paginated content (hot/essence/latest/unanswered), question/answer/article/pin details, paginated question answers, comments and replies, user profiles and content, collections and their contents, and loaded page text. Also supports interactions such as upvote/downvote/retract, comment likes, thank/no-help and retraction, following users/questions/topics, blocking/unblocking, favoriting/creating collections, commenting and replying, publishing/editing answers, asking questions, publishing articles, and deleting content the user has permission to remove.
让 AI 通过用户已登录的浏览器操作网站。一个 MCP 连接，按需发现站点能力，返回适合 AI 阅读的精简内容，无需复制 Cookie 或配置网站 API Key。
网站 | 主要能力 |
知乎 | 推荐、搜索、问题与回答、文章、评论、收藏及发布互动 |
推荐、搜索、社区、帖子与评论、收藏及发布互动 | |
WhatsApp Web | 会话与消息、联系人、群组、社群、频道和动态 |
X（Twitter / 推特） | 推荐首页、搜索、趋势、通知与未读计数、聊天、发帖回帖及互动 |
以上为当前源码的适配范围，下载包以对应版本为准。具体操作与参数由 site.discover 按需提供，部分能力取决于网站权限和登录状态。
Related MCP server: Chrome MCP Server
需要 Node.js 22+、Chrome 或 Edge 120+。MCP 与浏览器须运行在同一台电脑上；当前主要在 Windows 上验证。
从官网下载页获取浏览器扩展并解压到固定目录。
打开 chrome://extensions 或 edge://extensions，启用「开发者模式」，选择「加载已解压的扩展」，选中包含 manifest.json 的目录。
为 AI 客户端添加 MCP 服务，然后保持浏览器运行并登录要操作的网站。扩展会自动连接。
Codex：
codex mcp add nodelane-act -- npx -y --package=https://act.nodelane.net/downloads/nodelane-act-0.2.0.tgz nodelane-actClaude Code：
claude mcp add --transport stdio --scope user nodelane-act -- npx -y --package=https://act.nodelane.net/downloads/nodelane-act-0.2.0.tgz nodelane-act上述命令使用官网发布包。其他客户端配置、ZIP 和 MCPB 安装方式见安装说明。
连接后，直接向 AI 描述任务，例如：
“查看知乎推荐的前 5 条，只给标题、摘要和来源链接。”
“在 Reddit 搜索自托管相关讨论，展开最相关帖子的评论。”
“查看 X 首页推荐，同时告诉我通知和聊天的未读数量。”
“查看 WhatsApp 的未读会话，整理需要回复的消息。”
MCP 只暴露三个工具，站点操作按需发现：
工具 | 用途 |
| 选择或打开网站标签页，获取目标标识 |
| 查找站点能力与操作参数 |
| 执行操作或继续读取结果 |
列表默认返回少量条目与摘要，保留来源链接，支持分页和按需展开正文。X 的 home 可一次返回推荐、趋势、账号及未读计数。发帖、回复和消息发送按用户指令执行；结果不确定的写入不会自动重试。
git clone https://github.com/Wy2926/nodelane-act.git
cd nodelane-act
npm ci
npm run build将 dist/extension 加载到浏览器，并将 node <项目绝对路径>/dist/server/index.js 配置为本地 stdio MCP。修改扩展代码后需重新构建并重新加载扩展。
List browser targets with opaque targetIds. With a site or supported URL, automatically open a tab if missing; set openIfMissing=false for a pure lookup. Never replaces existing tabs. Returns no page bodies or credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| site | No | ||
| openIfMissing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: it discloses auto-open semantics, that existing tabs are never replaced, and that credentials/page bodies are not returned. These are substantive traits that the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) do not convey. It could mention rate limits or side effects more explicitly, but the coverage is strong.
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?
Three tightly written sentences, each adding distinct information: what the tool does, how openIfMissing changes behavior, and safety boundaries. Zero waste, front-loaded with 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 3-param, no-output-schema tool with annotations covering safety traits, the description is complete enough: it covers the core action, the optional open behavior, and the non-return of sensitive data. It omits explicit notes on return shape or error conditions, but nothing critical is missing for correct invocation.
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% for all 3 parameters, so the description must compensate. It explains the behavior of openIfMissing and the roles of site/url ('with a site or supported URL'), adding meaningful semantics beyond the raw schema. Some ambiguity remains (e.g., what 'supported URL' means), but it is effective.
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?
States a specific verb and resource ('List browser targets') and explains what the targetIds are (opaque). It clarifies the resource but does not distinguish itself from site.discover or site.execute, so it falls short of the 5 that requires sibling differentiation.
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 a clear behavioral rule ('set openIfMissing=false for a pure lookup') that informs usage, and it states scope ('with a site or supported URL'). It lacks explicit when-to-use-this-vs-alternatives guidance against the sibling tools, but the openIfMissing toggle is a concrete usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover installed sites or relevant operations. site alone returns a compact catalog; site+query returns matching schemas; site+operation returns one exact schema. No unrelated website schemas are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| site | No | ||
| limit | No | ||
| query | No | ||
| offset | No | ||
| operation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds the scoping behavior 'No unrelated website schemas are returned' plus the three output modes, which is useful context beyond annotations. It doesn't cover pagination (limit/offset) or result ordering, so it's not richer than a 3.
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 sentences, front-loaded with purpose then mode behavior. The 'No unrelated website schemas are returned' clause is a deliberate scoping guarantee that 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?
No output schema, so the description should carry return-value information; it names the three conceptual return shapes (compact catalog, matching schemas, one exact schema), which is helpful. But pagination and two parameters are unexplained, and the sibling routing is missing, leaving notable gaps for a 6-param discovery tool.
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 explains the meaning of 'site', 'query', and 'operation' through the mode combinations (site alone, site+query, site+operation). It leaves 'url', 'limit', and 'offset' undocumented, but is otherwise the only source of parameter meaning.
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?
States a specific verb (Discover) and resource (installed sites / relevant operations), and explains the output varies by combination. It doesn't directly differentiate from siblings site.context and site.execute, so it falls short of a 5.
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 each mode is used (site alone = catalog, site+query = matching schemas, site+operation = exact schema), which gives implied usage. However, it never names the alternatives (site.context, site.execute) or states when to use this versus them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a discovered operation on a targetId using its exact args schema. User-authorized writes execute directly in the browser. Pass returned pagination args for the next website page. For cached oversized output pass only resultId, offset and maxChars, which never repeats an operation.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| offset | No | ||
| maxChars | No | ||
| resultId | No | ||
| targetId | No | ||
| operation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already disclose that the tool is not read-only, is open-world, and is destructive. The description adds useful context by clarifying that writes are user-authorized and execute directly in the browser, and that caching avoids repeating operations. It stops short of detailing permission requirements, side effects of different operation types, or error behavior, so it adds moderate value beyond the annotations.
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 three tight sentences that front-load the core action and then cover pagination and cached output. Every sentence contributes, though the cached-output sentence is slightly dense; overall it is efficient with no obvious filler.
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 zero schema coverage, no output schema, and a complex multi-use tool with annotations, the description covers the main operational modes but omits details about what operations are discoverable, how args map to specific operations, and any error or permission handling. It is adequate but leaves clear gaps for an agent to call correctly in all cases.
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?
With schema description coverage at 0%, the description compensates by explaining key parameter semantics: targetId identifies the target, args must match the operation's exact schema, and resultId with offset/maxChars is used for cached output. It does not describe the 'operation' parameter's expected values or constraints, but overall adds substantial meaning beyond what the schema provides.
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 states a specific verb ('execute') and resource ('discovered operation on a targetId'), which distinguishes it somewhat from siblings like site.discover and site.context. However, 'a discovered operation' is vague without explaining what operations are available or how they are obtained, leaving the exact purpose slightly nebulous.
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 usage for writes ('User-authorized writes execute directly in the browser') and for pagination ('Pass returned pagination args') and cached output ('for cached oversized output pass only resultId, offset and maxChars'). Yet it does not explicitly state when to use this tool versus the siblings site.discover or site.context, or when not to use it, leaving the routing guidance incomplete.
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.
v0.2.0site.contextsite.discoversite.executeScored across 3 tools
Each tool serves a distinct phase: site.context manages browser targets, site.discover retrieves operation schemas, and site.execute performs operations. The descriptions clearly delineate their roles, leaving little room for confusion.
All tools use a consistent 'site.' prefix and lowercase dot notation, but site.context is a noun while the others are verbs, a minor deviation from a uniform verb-based pattern.
Three tools are well-scoped for a meta-execution model: one to establish context, one to discover available operations, and one to execute them. This minimal surface avoids redundancy and each tool earns its place.
The set covers the core workflow of target selection, schema discovery, and execution, but lacks explicit tools for tab management (e.g., closing tabs) or direct page state inspection, which are minor gaps agents might work around via discovered operations.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
