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., "@vconsole-mcp show me the console logs from the connected mobile page"
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.
注意事项： vConsole 官方不提供 MCP 链接能力，请使用 https://github.com/Simonmie/vConsole/tree/dev 中的代码尝试。
Note: Official vConsole does not provide MCP connectivity. To try this integration, use the code from the linked
devbranch above.
Expose console logs, network requests, and explicitly authorized JavaScript execution from a mobile H5 page to MCP clients such as Codex and Claude Code.
flowchart LR
Agent["Codex / Claude Code"] <-->|"MCP stdio"| MCP["vconsole-mcp"]
MCP <-->|"WebSocket :8765"| Mobile["Mobile H5 + vConsole"]
Mobile --> Data["Console / Network stores"]Records stay in the mobile page and are read on demand; the MCP process does not need a database or cloud service.
pnpm install
pnpm build
node dist/index.jsThe process uses stdio for MCP and listens for mobile WebSocket connections on 0.0.0.0:8765 by default. Startup messages are written to stderr so the MCP transport remains valid.
Options can be passed as arguments or environment variables:
node dist/index.js --host 0.0.0.0 --port 8765
VCONSOLE_MCP_HOST=0.0.0.0 VCONSOLE_MCP_PORT=8765 node dist/index.jsAn optional pairing token prevents other pages from registering with the local bridge:
node dist/index.js --token your-development-token
VCONSOLE_MCP_TOKEN=your-development-token node dist/index.jsRelated MCP server: monkeysee
Build the project first, then register the absolute entry path.
codex mcp add vconsole -- node /Users/jiangkexian/Desktop/MCP/vConsole-MCP/dist/index.js
claude mcp add vconsole -- node /Users/jiangkexian/Desktop/MCP/vConsole-MCP/dist/index.jsWith a pairing token, pass the same value to the MCP process and the mobile page:
codex mcp add vconsole --env VCONSOLE_MCP_TOKEN=your-development-token -- node /Users/jiangkexian/Desktop/MCP/vConsole-MCP/dist/index.jsAfter publishing the package, clients can use:
codex mcp add vconsole -- npx -y vconsole-mcp
claude mcp add vconsole -- npx -y vconsole-mcpOnly one MCP process can listen on port 8765 at a time. Run either Codex or Claude Code, or assign different ports when using both concurrently.
list_pages: list connected mobile pages.
get_console_logs: read recent console records with optional level filtering.
get_network_requests: read recent network records with optional failure, URL, body, and limit filters.
execute_javascript: execute up to 100,000 characters of JavaScript in the page selected by its required pageId through runtime.evaluate. It requires explicit authorization from the mobile user in vConsole before the code runs. Arbitrary code may mutate page state or storage, expose sensitive data, and send network requests. The optional timeout is between 100 and 30,000 milliseconds and defaults to 8,000.
For the read tools, pageId is optional when one page is connected. execute_javascript always requires a pageId; call list_pages first to select the intended target.
The first three tools are read-only. execute_javascript is marked non-read-only, potentially destructive, non-idempotent, and open-world because arbitrary page code can change application state and communicate with external systems. It is the only execution capability exposed by this MCP package; no separate DOM, click, input, storage, or clear tools are provided.
Initialize the forked vConsole with an endpoint:
const vConsole = new VConsole({
mcp: {
endpoint: 'ws://192.168.1.100:8765',
token: 'your-development-token',
autoConnect: true,
allowJavaScriptExecution: false,
},
});Or connect later:
vConsole.mcp.connect('ws://192.168.1.100:8765');JavaScript execution is denied by default. Enable Allow JavaScript Execution in the vConsole MCP panel for the current page. The panel permission resets after a page reload; trusted automated test pages may instead initialize vConsole with allowJavaScriptExecution: true.
Use the computer's LAN IP instead of localhost, keep the phone and computer on the same network, and allow the Node.js process through the computer firewall when prompted. This initial version is intended for trusted development networks and keeps all captured data in the mobile page. For an HTTPS H5 page, put the WebSocket endpoint behind a trusted WSS reverse proxy or relay; browsers block an HTTPS page from opening ws:// mixed content.
Execute JavaScript in a connected mobile H5 page after explicit authorization in vConsole. Arbitrary code may mutate page state or storage, expose sensitive data, and send network requests.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| pageId | Yes | ||
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by specifying concrete consequences: arbitrary code may mutate page state or storage, expose sensitive data, and send network requests. This complements the destructiveHint and openWorldHint flags and warns the agent about the non-read-only, potentially harmful nature of the operation. There is no contradiction with 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 only two sentences long and both sentences carry essential information: the core action and the risk profile. It is front-loaded and free of fluff, making it easy for an agent to parse quickly.
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 description covers the authorization requirement and the main risks, but there is no output schema and the description does not state what the tool returns, how errors are reported, or how pageId relates to list_pages. For a high-complexity, high-risk tool, this leaves some important gaps for an agent trying to invoke it correctly.
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 any of the parameters (pageId, code, timeout). The parameter names are somewhat self-explanatory, but the description adds no guidance on how to obtain pageId, how code will be executed, or what timeout controls. This is a meaningful gap given the lack of schema descriptions.
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 action and target: 'Execute JavaScript in a connected mobile H5 page later explicit authorization in vConsole.' This clearly differentiates it from sibling tools like list_pages, get_console_logs, and get_network_requests, which are read-only inspection tools rather than code-execution tools.
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 one important precondition: explicit authorization in vConsole. However, it does not explicitly say when to prefer this tool over the sibling read-only tools, nor does it state when not to use it. The usage context is implied by the contrast with the sibling tools but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the latest console logs captured by vConsole on a connected mobile H5 page.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| limit | No | ||
| pageId | No | ||
| pluginId | No | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds minor context by saying 'latest' and specifying the vConsole source, but does not disclose behavior like buffer limits, return format, or whether logs require the page to have vConsole enabled.
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?
A single, front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose and context.
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 read-only tool with strong annotations, this is minimally viable. However, the absence of an output schema and the complete lack of parameter guidance means the agent is left to infer return shape and the roles of pageId/pluginId. The description is functional but bare.
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 should compensate for the four parameters, but it does not mention level, limit, pageId, or pluginId at all. The parameter names and schema constraints provide some self-explanatory meaning, but the description adds zero value for parameter 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 uses a specific verb ('Read'), identifies the exact resource ('console logs captured by vConsole on a connected mobile H5 page'), and clearly distinguishes itself from sibling tools like get_network_requests and execute_javascript. The purpose is immediately understandable.
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 provides clear context about when this tool is relevant: reading console logs captured by vConsole on a connected mobile H5 page. It does not explicitly mention alternatives or exclusions, but the sibling tool names make the differentiation obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the latest network requests captured by vConsole on a connected mobile H5 page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| pageId | No | ||
| failedOnly | No | ||
| includeBody | No | ||
| urlIncludes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by specifying 'latest', 'vConsole', and 'connected mobile H5 page', but it does not disclose output shape, ordering, or how filters behave. This is acceptable given annotations, but some behavioral detail is still left implicit.
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 with no filler or redundant wording. It front-loads the action and the resource, making the tool's purpose immediately clear. Every part of the sentence 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?
With 5 optional parameters and no output schema, the description is somewhat thin: it omits what each request record contains, how pagination works, and how filters like failedOnly or urlIncludes operate. However, the parameters are fairly self-explanatory and the annotations cover the safety profile, making the description minimally adequate for a read-only tool. More return-format detail would improve completeness.
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 0% description coverage, and the description does not explain the parameters limit, pageId, failedOnly, includeBody, or urlIncludes. The word 'latest' gives some meaning to limit, and the mobile page context partially clarifies pageId, but most parameter semantics are left to the agent to infer from names alone. The description does not adequately compensate for the schema gap.
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 action ('Read') and resource ('latest network requests captured by vConsole on a connected mobile H5 page'). This clearly distinguishes it from sibling tools like list_pages, get_console_logs, and execute_javascript. The source and scope are precise enough for an agent to recognize the tool's purpose.
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 when network request data from vConsole is needed, but it does not explicitly state when to use it over get_console_logs or other alternatives. No when-not or exclusion guidance is provided. The intended use case is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List mobile H5 pages currently connected through vConsole.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds the useful context that the result reflects pages 'currently connected through vConsole,' indicating a live snapshot, but it does not disclose return shape, ordering, or pagination.
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 filler. The verb and object are front-loaded, and every word contributes to understanding the tool's 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 parameterless, read-only listing tool with annotations covering safety and no output schema, the description is sufficient for an agent to select and invoke it correctly. No additional operational details are necessary.
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 is no parameter detail for the description to add. Per the baseline for parameterless tools, a 4 is appropriate.
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 ('List') and resource ('mobile H5 pages currently connected through vConsole'), making the tool's purpose unmistakable. It is also clearly distinct from sibling tools that handle console logs, network requests, and JavaScript execution.
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 you need the currently connected mobile H5 pages — but it does not explicitly mention alternatives or exclusions. Sibling tool names suggest differentiation, but the description itself leaves that inference to the agent.
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.0execute_javascriptget_console_logsget_network_requestslist_pagesEach tool targets a distinct vConsole debugging concern: page discovery, console logs, network requests, and JavaScript execution. There is no overlap among these purposes, making tool selection unambiguous.
All tool names follow a consistent verb_noun pattern: list_pages, get_console_logs, get_network_requests, execute_javascript. The verbs and nouns clearly reflect each tool's function.
Four tools is a lean but well-scoped count for a vConsole debugging server. Each tool covers a core workflow without redundancy or bloat.
The set covers the primary vConsole use cases: listing pages, reading console logs, viewing network requests, and executing JavaScript. Missing storage/system info panels are a minor gap, but they can often be accessed indirectly through execute_javascript.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A paid remote MCP for AI agent browser DevTools MCP, built to return verdicts, receipts, usage logs,
Live browser debugging for AI assistants — DOM, console, network via MCP.
Access Kernel's cloud-based browsers and app actions via MCP (remote HTTP + OAuth).
A paid remote MCP for AI agent browser MCP session, built to return verdicts, receipts, usage logs,
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Simonmie/vConsole-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
