Vite MCP 服务器现已发布 Blowback
Blowback 旨在支持各种 FE 开发服务器，而不仅仅是 Vite
向 FE 开发服务器添加模型上下文协议 (MCP) 服务器以支持与 Cursor 的集成。
FE开发服务器与MCP服务器集成
通过 MCP 捕获和传输浏览器控制台日志
基于检查点的日志管理
Related MCP server: Blowback
将服务器添加到您的 Cursor MCP 配置中：
{
"blowback": {
"command": "npx",
"args": ["-y", "blowback-context"]
}
}用于检索浏览器控制台日志的资源。
注意：Cursor 目前不支持 MCP 资源功能。请使用get-console-logs工具。
用于捕获和管理屏幕截图的资源。
注意：与其他资源一样，Cursor 目前不直接支持此功能。请使用capture-screenshot工具。
工具名称 | 描述 |
| 检索最近的 HMR 事件 |
| 检查 HMR 状态 |
工具名称 | 描述 |
| 启动浏览器实例并导航到 Vite 开发服务器 |
| 截取当前页面或特定元素的屏幕截图。屏幕截图将保存到磁盘。由于 MCP 客户端的限制，您可能需要手动将保存的屏幕截图传输到编辑工具中。 |
| 检索特定元素的属性和状态信息 |
| 检索特定元素的样式信息 |
| 检索特定元素的尺寸和位置信息 |
| 在指定的时间内监控浏览器中的网络请求 |
| 检索特定元素及其子元素的 HTML 内容 |
| 使用可选的过滤功能从浏览器会话中检索控制台日志 |
| 安全地执行预定义的浏览器命令 |
工具名称 | 描述 |
| 提供有关如何使用该工具的说明 |
所有浏览器控制台日志都存储在日志文件中
您可以使用get-console-logs工具查询特定检查点的日志
检查点用于管理特定版本的快照、日志、截图等
当<meta name="__mcp_checkpoint" data-id="">插入到head时，数据会以 data-id 属性作为标识符单独记录
MCP Server ：基于模型上下文协议 SDK 的中央模块，为 MCP Client 提供工具。
浏览器自动化：使用 Puppeteer 控制 Chrome 来直观地检查变化。
检查点系统：维护浏览器状态的快照以供比较和测试。
服务器维护几个重要的数据存储：
HMR 事件记录：跟踪来自 Vite 的最近的 HMR 事件（更新、错误）。
控制台消息日志：捕获浏览器控制台输出以进行调试。
检查点存储：存储浏览器状态的命名快照，包括 DOM 快照。
MCP 客户端 → 开发服务器：
MCP 客户端更改源代码，开发服务器检测到更改
开发服务器自动更新浏览器或发出 HMR 事件
Web 浏览器 → MCP 服务器：
HMR 事件和控制台日志通过 Puppeteer 捕获。
MCP 服务器查询浏览器的当前状态或截取屏幕截图
MCP 服务器 → MCP 客户端：
服务器将 HMR 事件转换为结构化响应。
为 MCP 客户端提供查询 HMR 状态和捕获屏幕截图的工具。
服务器维护以下引用对象：
当前浏览器和页面实例
最近的 HMR 活动
Evaluates JavaScript code directly in the browser context and returns the result. Supports expressions, function strings, and complex code with automatic execution handling. Can target the entire page or work with element handles for precise DOM manipulation.
Examples:
Simple expression: "document.title"
Arrow function: "() => document.querySelectorAll('a').length"
Regular function: "function() { return document.body.children.length; }"
Function with arguments: "(tag) => document.getElementsByTagName(tag).length"
Complex code: "() => { const divs = document.querySelectorAll('div'); return { count: divs.length, hasClass: divs[0]?.className }; }"
Async function: "async () => { const res = await fetch('/api'); return res.json(); }"
| Name | Required | Description | Default |
|---|---|---|---|
| function | Yes | JavaScript code to execute (expression or function string). Examples: - Expression: "document.title" - Arrow function: "() => document.querySelectorAll('a').length" - Regular function: "function() { return document.body.children.length; }" - With arguments: "(tag) => document.getElementsByTagName(tag).length" - Async function: "async () => { const res = await fetch('/api'); return res.json(); }" | |
| args | No | Optional arguments to pass to the JavaScript function. Can be primitives, objects, arrays, or element references. Example: { url: "https://example.com", count: 5 } | |
| element | No | CSS selector to target specific element for evaluation | |
| contextId | No | Browser ID to execute on (uses most recent browser if not provided) | |
| timeout | No | Execution timeout in milliseconds (default: 30000) | |
| returnType | No | Expected return type for better serialization (default: auto) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure, and it does a solid job: it states that arbitrary JavaScript is evaluated, that expressions, functions, async functions, and complex code are supported, that results are returned, and that execution can target the whole page or an element. It does not warn about side effects or serialization edge cases, but the examples and execution modes give an agent a clear picture of how the tool behaves.
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 core purpose is front-loaded in the first sentence, and the examples are useful for conveying accepted code shapes. Some redundancy exists because the examples in the description mirror those already present in the schema's function property, but the description remains compact and scannable rather than bloated.
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 main invocation contract and code formats, and the schema fills in the remaining parameter semantics. However, there is no output schema and no mention of how results are serialized or what error behavior looks like, which leaves some ambiguity for a complex JavaScript-evaluation tool. It is adequate for basic use but not fully complete.
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 covers all six parameters with descriptive text, including detailed examples for the function parameter and explanations for args, element, timeout, contextId, and returnType. The description adds little beyond what the schema already provides, so the baseline score of 3 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 clearly states that this tool evaluates JavaScript in the browser context and returns a result, with explicit mention of targeting either the page or a specific element. It is distinct in function from the sibling DOM inspection and screenshot tools, but it does not explicitly differentiate itself from execute-browser-commands, so it falls just 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?
No explicit guidance is given about when to choose this tool over alternatives such as execute-browser-commands, get-element-properties, or capture-screenshot. The examples illustrate accepted code formats but do not state when this tool is the right choice or when a sibling would be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Captures a screenshot of the current page or a specific element. Stores the screenshot in the MCP resource system and returns a resource URI. If ENABLE_BASE64 environment variable is set to 'true', also includes base64 encoded image in the response.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | No | CSS selector to capture (captures full page if not provided) | |
| url | No | URL to navigate to before capturing screenshot. Do not provide if you want to capture the current page. | |
| contextId | No | Browser ID to capture from (uses most recent browser if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It does disclose useful behavior: the screenshot is stored in the MCP resource system, a resource URI is returned, and base64 output is conditional on an environment variable. However, it does not mention that providing a URL causes the browser to navigate first, nor does it state that an active browser/context is required.
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 and front-loaded: the core capability appears in the first sentence, followed by return behavior and the conditional base64 detail. Every sentence earns its place with no repeated or extraneous 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?
The description explains the return mechanism (resource URI and conditional base64) despite the lack of an output schema, which is helpful. However, it omits important operational context: a browser must already be running or otherwise available, and the navigation side effect when url is supplied is not surfaced in the main description. These are meaningful gaps for an agent deciding whether and how to invoke the 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 100%, so the schema already documents url, selector, and contextId clearly. The description adds little parameter meaning beyond echoing the current-page versus element distinction, which is already present in 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 a specific action ('Captures a screenshot') with a clear resource scope: the current page or a specific element. It is immediately distinguishable from the sibling get-element-* and browser-evaluate tools, which are about inspecting properties and running scripts rather than producing a screenshot.
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 a screenshot is needed—but it does not explicitly state when not to use it or name alternative tools. The optional URL, selector, and contextId guidance lives only in the schema, so the natural-language description alone gives no usage context beyond the obvious screenshot case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Closes a specific browser instance
| Name | Required | Description | Default |
|---|---|---|---|
| contextId | Yes | ID of the browser to close |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral implications. It does not mention side effects of closing (e.g., whether open tabs are lost, whether the process is terminated, whether it is reversible), nor does it state what happens if the contextId is invalid. For 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 a single efficient sentence with no filler words. It clearly communicates the action and target without redundancy or unnecessary detail.
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 one-parameter tool, the description is minimally adequate. However, because there is no output schema and no annotations, it does not explain how to discover contextId, whether the operation returns a value, or how errors are handled. This leaves an agent without enough context for fully reliable 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?
The input schema covers the only parameter, contextId, with the description 'ID of the browser to close,' giving 100% schema coverage. The tool description does not add additional meaning beyond the schema, so the baseline 3 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 uses a clear verb and resource: 'Closes a specific browser instance.' This distinguishes it from siblings like start-browser and list-browsers by naming the action and target. It could be slightly improved by noting that the instance is identified via contextId, but the core 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?
No guidance is given on when to use this tool versus alternatives like start-browser or list-browsers, nor is there any mention of how to obtain contextId. The description implies usage only at the most basic level ('close something'), without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes a sequence of predefined browser commands safely. Available commands:
click: Clicks on an element matching the selector or at specified coordinates
type: Types text into an input element
wait: Waits for an element, a specified time period, or a condition
navigate: Navigates to a specified URL
select: Selects an option in a dropdown
check: Checks or unchecks a checkbox
hover: Hovers over an element
focus: Focuses an element
blur: Removes focus from an element
keypress: Simulates pressing a keyboard key
scroll: Scrolls the page or an element
getAttribute: Gets an attribute value from an element
getProperty: Gets a property value from an element
drag: Performs a drag operation from one position to another
refresh: Refreshes the current page
Note on coordinates: For all mouse-related commands (click, drag, etc.), coordinates are relative to the browser viewport where (0,0) is the top-left corner. X increases to the right, Y increases downward.
Examples are available in the schema definition.
| Name | Required | Description | Default |
|---|---|---|---|
| commands | Yes | Array of commands to execute in sequence | |
| timeout | No | Overall timeout in milliseconds (default: 30000) | |
| contextId | No | Browser ID to execute commands on (uses most recent browser if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior on its own. It only says 'safely' and lists commands, without noting side effects, sequential execution semantics, error/failure behavior, or return value shape. The coordinate reference note is helpful, but the description does not disclose that commands can navigate, click, mutate state, or that continueOnError controls failure handling.
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 moderately sized and well-structured: a one-line summary, a scannable command list, and a focused coordinate note. There is no fluff, and the pointer to examples in the schema avoids unnecessary duplication.
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 is highly complex with 15 command types and per-command args, and the schema handles that well. However, the description does not explain what the tool returns, whether commands execute in order, what happens on failure, or how timeout and contextId interact. For an agent deciding whether to use this plus how to interpret results, these are material gaps.
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 100%, so the baseline is 3. The description adds value with the coordinate-system note: for mouse commands coordinates are viewport-relative with (0,0) at top-left, which is not fully explicit in the individual parameter descriptions. The command list also clarifies the allowed command vocabulary.
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 clear verb and resource: 'Executes a sequence of predefined browser commands safely.' The appended command list makes the scope concrete and distinct from single-action sibling tools like capture-screenshot or get-element-properties. It is specific, not tautological.
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 given on when to prefer this tool over individual browser tools, when a sequence is needed, or when a more targeted sibling like browser-evaluate or get-element-properties would be better. The word 'sequence' implies multi-step use, but that is left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves console logs from the development server
| Name | Required | Description | Default |
|---|---|---|---|
| checkpoint | No | If specified, returns only logs recorded at this checkpoint | |
| limit | No | Number of logs to return, starting from the most recent log |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It establishes a read-oriented retrieval action and specifies the source as the development server, but it does not describe whether logs are paginated, what 'limit' does exactly, what a checkpoint is, or how the returned logs are structured.
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, front-loaded sentence with no wasted words. It names the action, the target, and the environment in a compact way.
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 two optional, fully described parameters, the description is minimally viable. However, it lacks any statement about expected return shape, prerequisites such as a running development server, or when not to use this tool, and there is no output schema or annotations to cover those gaps.
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 schema already documents both parameters with 100% coverage, so the description adds little parameter-level meaning. The description does not explain how limit and checkpoint interact, but the schema descriptions are sufficiently detailed to set a baseline of 3.
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 ('Retrieves') and a specific resource ('console logs'), and 'from the development server' gives scope. It does not explicitly contrast with sibling tools like get-hmr-events or get-context-stats, but the resource name is distinct enough to make the tool's purpose identifiable.
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 no guidance about when to prefer this tool over alternatives. There is no mention of use cases, exclusions, or sibling tools, so an agent is left to infer context purely from the name and the short description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets detailed information about a specific browser instance
| Name | Required | Description | Default |
|---|---|---|---|
| contextId | Yes | ID of the browser to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only says 'gets detailed information,' which is the bare operation; it does not clarify what information is included, whether the call is read-only, or what errors or edge cases may occur.
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 short sentence with no filler, and the key action is front-loaded. It is concise, though slightly vague by using 'detailed information' without elaboration.
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 no output schema, the description should convey what kind of detailed information the agent will receive, but it does not. It also leaves ambiguity with the sibling get-context-stats, making the definition incomplete for an agent deciding which tool to invoke.
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 100%, and the single required parameter contextId is already described as 'ID of the browser to inspect.' The description adds no additional semantic meaning beyond the schema, so the baseline score of 3 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 clear verb ('gets') and resource ('detailed information about a specific browser instance'), so the core action is understandable. However, it does not distinguish this from get-context-stats, which sounds closely related, so it misses the full sibling-differentiation bar.
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 no guidance on when to use this tool instead of alternatives like get-context-stats, list-browsers, or get-context-info-related tools. There are no conditions, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets usage statistics for browsers
| Name | Required | Description | Default |
|---|---|---|---|
| contextId | No | Specific browser ID (returns stats for all browsers if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not state it explicitly, doesn't explain what 'usage statistics' contains, and gives no details about return format, side effects, or implications of omitting contextId. The parameter description partially covers the default-all behavior, but the tool description itself reveals almost nothing.
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, and it is appropriately front-loaded with the action and resource. It is concise but slightly under-specified; nonetheless, structure is not the issue.
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 no output schema, no annotations, and a loosely defined 'usage statistics' term, the description is incomplete for an agent to know what response to expect or when this tool is the right choice. The optional parameter behavior is in the schema, but the core meaning of the returned stats is missing, making the overall definition insufficient for confident 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 100% and the sole parameter, contextId, is well-described in the schema as optional with a clear default behavior. The tool description adds no additional parameter meaning, but none is needed since the schema already explains the semantics. Baseline 3 applies here.
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 ('Gets') and resource ('usage statistics for browsers'), which conveys a read operation on browser usage data. However, 'usage statistics' is vague—it doesn't specify whether these are CPU/memory metrics, session counts, or something else—so it leaves room for interpretation. It is still distinguishable from siblings like get-context-info and get-console-logs, but not precisely.
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 no guidance on when to use this tool versus alternatives such as get-context-info or get-console-logs. There are no stated conditions, exclusions, or references to sibling tools, leaving the agent to infer appropriate 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.
Retrieves dimension and position information of a specific element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector of the element to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool reads dimension/position data but omits any detail about coordinate system (viewport/document), units, behavior when selector matches no element, or whether layout must be settled. This is a meaningful ambiguity.
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?
One short sentence with no filler; the core information is front-loaded and concise.
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?
Without an output schema, the description should specify the return structure (e.g., width, height, x/y coordinates and coordinate system). It gives a high-level summary that is minimally viable but leaves important operational details undefined.
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 of the selector parameter, so the schema already fully documents the input. The tool description adds no parameter-specific meaning, but the baseline of 3 applies.
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?
Clearly states the action (retrieves) and resource (dimension and position information of a sspecific element). The resource is specific enough to distinguish from sibling getters like get-element-styles or get-element-html, though it doesn't explicitly name an alternative.
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 on when to choose this tool over siblings such as get-element-properties or get-element-styles. The description only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the HTML content of a specific element and its children with optional depth control
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector of the element to inspect | |
| includeOuter | No | If true, includes the selected element's outer HTML; otherwise returns only inner HTML (default: false) | |
| depth | No | Control HTML depth limit: -1 = unlimited (default), 0 = text only, 1+ = limited depth with deeper elements shown as <!-- omitted --> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states the tool returns HTML and supports depth control, but it does not describe the exact return payload or any side effects. For a read-only inspection tool, this is a modest but acceptable 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?
A single, front-loaded sentence conveys the core action, target, scope, and key option. There is no redundant wording or repetition of schema details.
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 relatively simple read-only tool with three parameters, the description plus fully documented schema provides enough information to invoke it correctly. It does not explain the exact return format, but that omission is minor given the availability of output examples over time and the clear purpose.
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 the baseline is 3. The description adds meaning by clarifying that the tool returns content for the element and its children, which goes beyond individual parameter descriptions and helps interpret depth and includeOuter behavior.
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 ('Retrieves') with a concrete resource ('HTML content of a specific element and its children') and mentions depth control. This clearly distinguishes it from sibling inspection tools like get-element-properties or get-element-styles.
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?
Usage context is implied: this tool should be used when HTML content is needed, as opposed to properties, styles, or dimensions. However, it does not explicitly say when not to use it or mention alternatives to consider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves properties and state information of a specific element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector of the element to inspect | |
| properties | Yes | Array of property names to retrieve (e.g., ['value', 'checked', 'textContent']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Retrieves' implies a read operation, but the description does not mention what happens for non-existent elements, invalid property names, missing selectors, or whether the tool returns raw values, computed values, or serialized objects. This leaves meaningful behavioral gaps for an agent.
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 clear sentence with no filler and no repetition. The core action and target are front-loaded, making it easy to parse and remember.
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 two-parameter read tool with fully documented schema, the description is minimally viable. However, with no annotations and no output schema, it would benefit from stating return behavior or edge cases (e.g., error when element is not found). It is adequate but not thorough.
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 100%, so the input schema already fully documents both `selector` and `properties` with examples. The description adds little beyond the phrase 'state information,' which hints at properties like checked or selected but does not materially extend what the schema already provides. Baseline 3 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 uses a specific verb ('Retrieves') and identifies the resource ('properties and state information of a specific element'). It distinguishes from sibling tools like get-element-styles, get-element-dimensions, and get-element-html by focusing on arbitrary properties and state, though it does not explicitly name those alternatives.
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 no guidance on when to use this tool versus get-element-styles, get-element-dimensions, get-element-html, or browser-evaluate. There are no stated exclusions, prerequisites, or alternative-selection hints, so an agent must infer the appropriate use case from the tool list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves style information of a specific element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector of the element to inspect | |
| styleProperties | Yes | Array of style property names to retrieve (e.g., ['color', 'fontSize', 'backgroundColor']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Retrieves style information' without specifying whether these are computed styles, inline styles, what happens if the element is missing, or the format of the returned values. It does not contradict any annotations, but it is far too minimal.
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 redundant wording. It is front-loaded with the action and resource, making it easy to scan, though some brevity comes at the cost of missing behavioral 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?
With no annotations and no output schema, the description should provide more context about return values, computed versus inline style semantics, and error behavior. The schema covers the parameters, but the overall behavioral contract is incomplete for an agent deciding how to use this 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 100%, so both parameters are already documented with clear descriptions and an example for styleProperties. The description adds no parameter-level meaning, so a baseline score of 3 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 clearly states the verb 'Retrieves' and the resource 'style information of a specific element', making the tool's purpose understandable. It also differentiates well from sibling tools like get-element-properties and get-element-dimensions, though it does not explicitly contrast with them.
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 over alternatives such as get-element-properties, get-element-html, or browser-evaluate. The name implies a use case, but the description offers no conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves recent HMR events
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of events to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure, but only restates the basic action. It doesn't mention side effects, whether events are cleared on retrieval, how 'recent' is defined, or the source/scope of the events. This leaves the agent unaware of important behavioral nuances.
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 redundancy, and the core action is front-loaded. It is appropriately brief for a simple getter, though the lack of supporting context limits its overall usefulness.
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 annotations, no output schema, and no description of return structure or scope. In a suite of browser tools with similar log/event retrieval functions, the description doesn't clarify what HMR events are or when to use this tool, making it insufficient for fully informed selection and 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?
The input schema already describes the only parameter, limit, with 100% coverage, so the baseline is 3. The description adds no extra meaning about limit usage, but none is required given the schema's clarity.
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 'Retrieves recent HMR events' states a specific verb and object, clearly identifying the tool's function. It names a distinct resource type (HMR events) that isn't covered by any sibling, though it doesn't explicitly explain the acronym or contrast with alternatives.
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 no information about when to use this tool versus its siblings such as get-console-logs or monitor-network. There are no exclusions, preconditions, or context cues to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Description of how to use the server
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Section to describe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses nothing about side effects, return shape, prerequisites, or limitations. The text is a placeholder and adds no transparency about how the tool behaves.
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 short but not usefully concise; it is under-specified placeholder text that does not earn its place. A single vague sentence without concrete content is closer to omission than to effective 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?
Even though the tool is simple with one parameter, the description gives an agent almost nothing to work with. It does not explain what 'checkpoint' or 'hmr' sections contain, what the output looks like, or how this tool fits into the broader browser automation context. This is incomplete for reliable 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 100%, including a meaningful enum and description for the 'section' parameter. Per the rubric, this warrants a baseline 3 even without parameter details in the description. The description adds no extra parameter meaning, but the schema already documents the single parameter adequately.
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 is a tautology: "Description of how to use the server" essentially restates the tool name without saying what the tool actually does. It does not specify a concrete verb, what resource it operates on, or what outcome the agent can expect.
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 no guidance on when to use this tool versus the many sibling tools. There is no context, no alternatives, and no exclusions. The section enum hints at checkpoint/hmr content, but the description itself gives no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all active browser instances
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by browser type | |
| tags | No | Filter by tags | |
| includeStats | No | Include usage statistics (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. The verb 'Lists' strongly implies a non-mutating read operation, which is helpful. However, it does not clarify how 'active' is determined, whether filters combine, or what the response contains beyond the inferred list of browsers.
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, front-loaded sentence with no filler or redundant content. Every word contributes meaning, and it communicates the core intent immediately.
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 low-complexity read-only listing tool with no required parameters and fully documented optional filters, the description is reasonably complete. It does not detail return shape or edge cases like zero active instances, but those are minor given the simplicity of the operation.
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 100%, so the input schema already documents all three parameters (tags, type, includeStats) with adequate descriptions. The tool description itself adds no additional parameter-level detail, so the baseline score of 3 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 'Lists all active browser instances' uses a specific verb ('Lists'), a clear resource ('browser instances'), and a scope qualifier ('active'). It is clearly distinct from sibling operations like start-browser or close-browser, though it does not explicitly differentiate from get-context-info or other query-like 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 usage context is implied: use this when you need to see currently active browser instances. However, there is no explicit guidance about when to prefer list-browsers over related tools like get-context-info, nor any mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitors network requests in the browser for a specified duration
| Name | Required | Description | Default |
|---|---|---|---|
| urlPattern | No | URL pattern to filter (regex string) | |
| duration | No | Duration in milliseconds to monitor (default: 5000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. 'Monitors' suggests passive, non-destructive observation, which is useful, but the description does not disclose whether results are returned immediately, whether the tool blocks until the duration elapses, or how filtered requests are surfaced. Basic transparency, but not rich behavioral detail.
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, focused sentence that front-loads the main purpose and includes the key variable. There is no fluff or repetition, so 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?
With no output schema and no annotations, the description should clarify what the result looks like and whether the tool has side effects. It says only that it 'monitors'network requests, leaving the agent unknowing about return format, timeouts, default behavior, or empty-result handling. For a simple tool this is minimally usable, but incomplete.
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 100%, so the parameters are already documented by the schema. The description reinforces the 'duration' concept but adds no meaning beyond the schema for urlPattern. Baseline 3 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 clearly states the action ('Monitors'), the resource ('network requests in the browser'), and the primary scoping input ('for a specified duration'). This distinguishes it from siblings like get-console-logs and get-hmr-events, which target different data streams.
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 network request monitoring is needed—but it does not explicitly explain when to prefer it over alternatives or when not to use it. It provides enough context, but no exclusions or sibling routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new browser context with an auto-generated unique ID
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Browser type (default: chromium) | |
| displayName | No | Human-readable name for the browser | |
| targetUrl | No | URL to navigate to after starting | |
| headless | No | Run browser in headless mode (default: false) | |
| viewport | No | Browser viewport size (default: 1280x800) | |
| tags | No | Tags for organizing browsers | |
| purpose | No | Description of what this browser is for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses that an ID is auto-generated, but it does not say that this launches a persistent browser process, that the instance can later be closed with close-browser, or what happens after creation. The lifecycle and side-effect behavior is left unexplained.
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 with no filler and front-loads the action and resource. It is efficient, but at nine words it is arguably too terse for a tool with seven optional parameters and no annotations, so it does not earn a 5.
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 no output schema, the description should say what the tool returns and how to use the generated ID with sibling tools, but it only hints at an auto-generated ID. It also omits the persistence/cleanup lifecycle. The full parameter schema prevents this from being a 1, but the missing output and lifecycle context is significant.
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 documents all 7 parameters with descriptions, so the baseline is 3. The description adds no parameter-level detail beyond clarifying that the ID is auto-generated, which helps explain why no ID parameter is needed. That is marginal but sufficient.
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 names a specific action ('Creates'), a specific resource ('new browser context'), and an outcome ('auto-generated unique ID'). This clearly separates start-browser from siblings list-browsers and close-browser, which manage existing contexts.
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 verb and 'new' imply this tool should be used when a fresh browser context is needed, but the description does not explicitly state when not to use it or point to alternatives such as list-browsers for existing contexts. No prerequisites or cleanup guidance is provided.
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.
v1.0.0browser-evaluatecapture-screenshot1 field changedInput schema / properties / contextIdAdded value: +{
+ "description": "Browser ID to capture from (uses most recent browser if not provided)",
+ "type": "string"
+}close-browserexecute-browser-commands1 field changedInput schema / properties / contextIdAdded value: +{
+ "description": "Browser ID to execute commands on (uses most recent browser if not provided)",
+ "type": "string"
+}get-context-infoget-context-statsget-element-html1 field changedInput schema / properties / depthAdded value: +{
+ "description": "Control HTML depth limit: -1 = unlimited (default), 0 = text only, 1+ = limited depth with deeper elements shown as <!-- omitted -->",
+ "minimum": -1,
+ "type": "integer"
+}list-browsersstart-browser7 fields changedInput schema / properties / displayNameAdded value: +{
+ "description": "Human-readable name for the browser",
+ "type": "string"
+}Input schema / properties / headless / descriptionPrevious value: -"Run browser in headless mode"New value: +"Run browser in headless mode (default: false)"Input schema / properties / purposeAdded value: +{
+ "description": "Description of what this browser is for",
+ "type": "string"
+}Input schema / properties / tagsAdded value: +{
+ "description": "Tags for organizing browsers",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / targetUrl / descriptionPrevious value: -"URL of the dev server (default: http://localhost:5173)"New value: +"URL to navigate to after starting"Input schema / properties / typeAdded value: +{
+ "description": "Browser type (default: chromium)",
+ "enum": [
+ "chromium",
+ "firefox",
+ "webkit"
+ ],
+ "type": "string"
+}Input schema / properties / viewportAdded value: +{
+ "additionalProperties": false,
+ "description": "Browser viewport size (default: 1280x800)",
+ "properties": {
+ "height": {
+ "type": "number"
+ },
+ "width": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+}capture-screenshotexecute-browser-commandsget-console-logsget-element-dimensionsget-element-htmlget-element-propertiesget-element-stylesget-hmr-eventshow-to-usemonitor-networkstart-browserScored across 16 tools
Each tool has a clearly distinct purpose: browser lifecycle (start, close, list), interaction (evaluate, screenshot, command sequence), inspection (element dimensions, HTML, properties, styles), and Vite-specific (console logs, HMR events, network monitor). No ambiguous overlap.
All tool names use a consistent hyphenated lowercase verb-noun pattern (e.g., get-element-html, list-browsers, start-browser). Naming is predictable and uniform.
16 tools is slightly above the ideal range of 3-15, but the set is well-scoped for the server's dual purpose of Vite dev server interaction and browser automation, without feeling bloated.
The tool set covers the full lifecycle (start, close, list), interactions (evaluate, screenshot, command sequences), element inspection, and Vite-specific diagnostics (console logs, HMR events, network monitoring). No obvious gaps for the intended use case.
Give AI coding agents access to your Vynix visual feedback, bug reports, and AI diagnosis.
Comment on AI-generated webpages; feedback flows back to your coding agent. Free, MIT, local-first.
Shared memory for AI coding agents. Save once, reuse from Cursor, Claude Code, Codex.
Bring meeting decisions, tasks and user stories into your AI editor (Claude, Cursor, Copilot).
