Requires Node.js 20 or higher to run the MCP server and connect to Vite development environments.
Leverages Puppeteer for browser automation to capture screenshots, monitor console logs, inspect element properties, track network requests, and create checkpoints for visual verification during Vite development.
Integrates with Vite's Hot Module Replacement (HMR) system to enable real-time code updates. Allows monitoring HMR events, connecting to a running Vite dev server, and observing live updates when code is modified.
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., "@Vite MCP Server capture a screenshot of the homepage and check the HMR status"
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.
Vite MCP Server is now Blowback
Blowback aims to support various FE development servers, not only Vite
A Model Context Protocol (MCP) server that integrates FE development servers with AI tools like Claude Desktop and Cursor.
Command (Claude Code):
claude mcp add blowback -s project -e PROJECT_ROOT=/path/to/your/project -- npx -y blowback-contextOr use json configuration:
Claude Code: {PROJECT_ROOT}/.mcp.json
Cursor: {PROJECT_ROOT}/.cursor/mcp.json
{
"mcpServers": {
"blowback": {
"command": "npx",
"args": ["-y", "blowback-context"],
"env": {
"PROJECT_ROOT": "/path/to/your/project"
}
}
}
}PROJECT_ROOT: Project root path (optional, defaults to current working directory)
ENABLE_BASE64: Include base64 encoded images in tool responses (default: false / affects token usage and context window when enabled)
Related MCP server: Blowback
Integration of local development server with MCP server
Browser console log capture and transmission via MCP
Checkpoint-based log management
Screenshot capture and SQLite database management
HMR (Hot Module Replacement) event monitoring
Browser automation and element inspection
The init prompt provides guidance to AI assistants on how to effectively use the following features:
Cursor Chat does not support MCP prompt functionality, so this feature is not available. (Claude Code recommended) If needed, manually input the following prompt:
You can use checkpoint features by inserting
<meta name="__mcp_checkpoint" data-id="">into the head to create a named snapshot of the current state. The data-id attribute is a unique identifier for the checkpoint.Console logs generated in the browser while a checkpoint is active are tagged with the checkpoint ID and can be queried individually.
Note: In some development environments, hot reload is triggered when files are saved, so carefully consider the sequence between meta tag changes and the changes you want to observe. Make sure to set the checkpoint meta tag before making the changes you want to track.
You can use the capture-screenshot tool to take screenshots. The captured screenshots are stored in the @.mcp_screenshot/ directory.
Tool Name | Description |
| Retrieves recent HMR events |
| Checks the HMR status |
Note: HMR connection is optional, not required. HMR event monitoring starts automatically when the browser is launched.
Tool Name | Description |
| Starts a browser instance and navigates to the development server. HMR monitoring starts automatically |
| Captures a screenshot of the current page or a specific element. Returns screenshot ID and resource URI |
| Retrieves properties and state information of a specific element |
| Retrieves style information of a specific element |
| Retrieves dimension and position information of a specific element |
| Monitors network requests in the browser for a specified duration |
| Retrieves the HTML content of a specific element and its children |
| Retrieves console logs from the browser session with optional filtering |
| Safely executes predefined browser commands |
Tool Name | Description |
| Provides instructions on how to use specific features of the server |
A resource for querying all captured screenshots. You can query screenshot reference IDs captured by the capture-screenshot tool using various criteria.
Images corresponding to reference IDs are managed in the {PROJECT_ROOT}/.mcp_screenshot/ directory.
URI: screenshot://
Returns a list of all screenshots
A resource for querying specific screenshots based on URL path.
Note: Starting from version 1.0, Blob responses through resources are disabled by default, and file reference information is returned instead
URI template: screenshot://{+path}
Example: screenshot://localhost:5173/about
Use URL paths without protocol (http://, https://)
Screenshot images: Stored in {PROJECT_ROOT}/.mcp_screenshot/ directory
Metadata: Managed in SQLite database in temporary directory
It's recommended to add .mcp_screenshot/ directory to .gitignore
Captures browser console logs and saves them to files for querying
Checkpoint logs are only saved when checkpoints are active
Checkpoints are used to manage snapshots, logs, screenshots, etc. of specific versions
When <meta name="__mcp_checkpoint" data-id=""> is inserted into the head, data is recorded separately using the data-id attribute as an identifier
MCP Server: Central module that exposes tools and resources to AI tools using the Model Context Protocol SDK.
Browser Automation: Uses Playwright to control Chrome for visual inspection, screenshot capture, and DOM manipulation.
Checkpoint System: Maintains snapshots of browser states for comparison and testing.
SQLite Database: Efficiently manages screenshot metadata and enables quick URL-based queries.
The server maintains several important data stores:
HMR Event Records: Tracks recent HMR events (updates, errors) from development server.
Console Message Logs: Captures browser console output for debugging.
Checkpoint Storage: Stores named snapshots of browser states including DOM snapshots.
Screenshot Storage: Saves images in project directory and manages metadata with SQLite.
MCP Client → Development Server:
MCP Client changes the source code and development server detects the change
Development server automatically updates the browser or emits HMR events
Web Browser → MCP Server:
HMR events and console logs are captured through Playwright
MCP Server queries the current state of the browser or captures screenshots
MCP Server → MCP Client:
The server converts HMR events into structured responses
Provides tools for MCP Client to query HMR status, capture screenshots, and more
The server maintains reference objects for:
Current browser and page instances
Recent HMR events
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?
The description mentions support for expressions, functions, async execution, and automatic handling, but lacks details on side effects, permissions, error behavior, or return value structure. With no annotations, this is only moderately transparent.
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 front-loaded with the core verb and includes a well-organized list of examples. It is slightly verbose with six example cases, but each adds clarity. Could be trimmed slightly without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description could explain return value format and error handling more clearly. The phrase 'returns the result' is vague, and 'automatic execution handling' lacks specifics. Sibling tools often provide more structured outputs.
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%, baseline 3. The description adds value by listing multiple example formats for the 'function' parameter, clarifying how to pass various JavaScript code snippets. However, other parameters are not further elaborated beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Evaluates JavaScript code directly in the browser context and returns the result.' It distinguishes from sibling tools like get-element-html or capture-screenshot by focusing on arbitrary 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 provides examples of what the tool can do but does not explicitly state when to use it versus alternatives like execute-browser-commands or get-element-properties. Usage is implied but not guided.
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 full burden. It discloses key behaviors: storing in the MCP resource system, returning a URI, optionally providing base64 based on environment variable, and the ability to capture specific elements or navigate to a URL first. This is transparent and sufficient.
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 sentences, each adding distinct information: core functionality, storage and return, and environmental optionality. No unnecessary words; it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three optional parameters and no output schema, the description covers all essential aspects: what the tool does, how parameters work, what the return includes (URI, optional base64). It fully addresses the needs 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?
The input schema already describes all three parameters (selector, url, contextId) well. The description adds value by explaining that omitting selector captures full page, url navigates before capture, and contextId defaults to most recent browser. This enriches the bare schema definitions.
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 'Captures a screenshot of the current page or a specific element', providing a specific verb and resource. It distinguishes from sibling tools (e.g., browser-evaluate, close-browser) which have different purposes, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how screenshots are stored and returned, but does not explicitly guide when to use this tool versus alternatives like browser-evaluate for visual inspection. It would benefit from stating that this is for visual capture rather than script-based evaluation.
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?
With no annotations, the description bears full responsibility for behavioral disclosure. It states the tool closes a browser instance but provides no details on consequences (e.g., resource cleanup), error states for invalid IDs, or whether the operation is reversible. This is a significant gap for a mutation tool.
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 extremely concise with a single sentence that directly conveys the core function. No unnecessary words or information is included, earning its place efficiently for a simple tool.
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 no output schema and no annotations, the description is too sparse. It fails to inform the agent about expected behavior on error, asynchronous nature, or confirmation of success. The tool's simplicity does not excuse the lack of essential operational context.
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% for the required parameter 'contextId', so the baseline is 3. The description does not add useful semantics beyond reiterating the tool's purpose; it neither clarifies the parameter's format nor provides contextual hints, but it meets the minimum standard.
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 ('Closes') and the resource ('a specific browser instance'), making the tool's purpose unambiguous. It effectively distinguishes itself from sibling tools like 'start-browser' and 'list-browsers' by specifying the closing operation.
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 lacks any guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as ensuring the browser exists, or when to prefer other related tools like 'execute-browser-commands' for more granular control.
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 provided, so the description must carry full behavioral disclosure. It mentions 'safely' but does not specify default error handling (e.g., stops on error unless continueOnError is set), side effects, or return value structure. The coordinate note is good, but critical execution behavior is missing, making it insufficient for an agent to anticipate outcomes.
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 structured with a bullet list and a note, which is readable. However, it is somewhat lengthy and includes 'Examples are available in the schema definition' which is redundant. Some sentences are not essential; it could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain return values and behavior. It does not mention that results per command are returned, how errors propagate, or the default timeout. Given the tool's complexity (15 command types, multiple optional parameters), the description lacks sufficient context for an agent to use it reliably.
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?
Input schema coverage is 100%, so the schema already describes all parameters. The description adds a helpful note about coordinate system (viewport-relative) and lists available commands, but this adds marginal value beyond the schema. The baseline of 3 is appropriate; the description does not significantly deepen 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 states 'Executes a sequence of predefined browser commands safely' and lists 15 specific commands with brief explanations. This clearly identifies the tool as a batch executor of browser actions. However, it does not explicitly differentiate from sibling tools like browser-evaluate or capture-screenshot, missing a chance to clarify when to use this instead of single-action 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 says the tool 'executes a sequence' and lists commands, implying it's for multi-step interactions. But it offers no explicit guidance on when to use this tool versus alternatives (e.g., use browser-evaluate for JS evaluation, capture-screenshot for screenshots). The lack of when-not-to-use or sister tool references reduces its helpfulness for agent selection.
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?
No annotations provided, so the description must disclose behavior. It only states the core function without explaining what happens with omitted parameters, output format, pagination, or side effects (e.g., whether logs are cleared).
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 wasted words. However, front-loading is not an issue, but it could be slightly more informative without sacrificing 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?
Given optional parameters and no output schema, the description should clarify default behavior (e.g., returns recent logs when no filters). It lacks information about return format and limits.
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% (both parameters have descriptions). The description adds no additional meaning beyond the schema, so 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 (retrieves) and resource (console logs from the development server). It distinguishes the tool's purpose from siblings like get-hmr-events, but does not explicitly differentiate from all siblings.
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 use this tool versus alternatives such as get-hmr-events. The description does not mention prerequisites, scenarios, or exclusions.
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?
With no annotations, the description carries full burden. It discloses no behavioral traits such as what happens with invalid contextId, whether it is read-only, or what 'detailed information' entails. This is insufficient for safe agent usage.
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 that conveys the core purpose without extraneous words. However, it could benefit from slightly more detail without becoming verbose.
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 the simplicity of the tool (1 parameter, no output schema), the description is adequate but incomplete. It fails to explain what constitutes 'detailed information' or any side effects, which would be important for an agent.
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% for the single parameter 'contextId', and its schema description is adequate ('ID of the browser to inspect'). The tool description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
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 'gets' and the resource 'detailed information about a specific browser instance'. It distinguishes from siblings such as 'list-browsers' which lists all instances, but does not differentiate from 'get-context-stats'.
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 usage guidelines are provided; the description does not indicate when to use this tool versus alternatives like 'get-context-stats' or 'list-browsers', nor does it mention prerequisites or context.
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, the description must disclose behavioral traits. It only restates the name's functionality without indicating that it is read-only, safe, or any side effects. No additional context beyond the tool name is provided.
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 that efficiently conveys the core purpose. While it could be more detailed, it is appropriately concise for such a tool.
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 lacks information about the return value (e.g., format, typical fields) despite no output schema. Given the tool returns statistics, the agent is left guessing what the response contains. Siblings like 'get-console-logs' likely provide structure, making this gap 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 schema describes the single parameter 'contextId' with a clear description, achieving 100% coverage. The description does not add any extra meaning, so it meets the baseline of 3 without improvement.
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 'Gets' and the resource 'usage statistics for browsers', distinguishing it from sibling tools like 'list-browsers' and 'get-context-info'. However, it lacks specificity on what 'usage statistics' entails (e.g., memory, CPU, activity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a browser ID from 'list-browsers', nor exclusions like using 'get-context-info' for detailed state.
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?
With no annotations provided, the description should disclose behavioral traits like side effects or permissions. It only states the action without noting that it is read-only, nor does it specify whether it waits for the element to exist. The minimal description does not compensate for the lack of 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 a single sentence that is front-loaded with the action and resource. No redundant information is present, and every part contributes to 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?
The tool has no output schema, and the description does not specify the return value (e.g., an object with width, height, x, y). Given that sibling tools like get-element-properties likely return different data, this omission makes the description incomplete for an AI agent to know what to expect.
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 100% of parameters and describes 'selector' as a CSS selector. The tool description adds no additional meaning beyond the schema, 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 it retrieves dimension and position information for a specific element, using the verb 'Retrieves' and specifying the resource. This distinguishes it from sibling tools like get-element-html or get-element-styles, though it could be more explicit about the scope (e.g., bounding rect).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., get-element-properties, get-element-styles). The description does not mention alternatives or pruning conditions, leaving the agent to infer from the tool names alone.
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?
With no annotations provided, the description carries the full burden. It explicitly mentions optional depth control and the includeOuter parameter, giving the agent a good understanding of the behavior. However, it does not disclose what happens on failure (e.g., element not found) or that it is a read operation (though that is implied).
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, well-structured sentence that front-loads the core purpose. Every word adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 optional parameters, no output schema), the description adequately covers the core functionality and parameter meanings. It lacks explicit error handling or return format details, but for a retrieval tool, this is acceptable. It is mostly 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 schema has 100% coverage, so the description does not need to add much. However, it enhances understanding by summarizing the depth feature ('optional depth control') and the schema already provides detailed descriptions for each parameter. The description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieves') and defines the resource ('HTML content of a specific element and its children'). It clearly distinguishes from sibling tools like get-element-properties or get-element-styles, which focus on different aspects of an element.
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 for retrieving HTML, but it does not explicitly state when to use it versus alternatives, nor does it provide any contextual guidance on prerequisites or exclusions. It meets the minimum viable standard.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'retrieves' without mentioning side effects, prerequisites (e.g., element must exist on page), or error behavior. For a getter, minimal behavioral context is needed, but the description is still sparse.
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, making it concise and front-loaded. No unnecessary words, but it could benefit from slight elaboration on scope (e.g., current page 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?
The tool lacks an output schema and annotations, and the description provides no information about return format or behavior. Given its simplicity and the presence of many sibling tools, the description is too brief to be 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?
Both parameters are fully described in the input schema (selector and properties). The description adds no additional meaning beyond the schema, so baseline 3 applies given 100% schema coverage.
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 it retrieves properties and state information of a specific element. However, it does not differentiate from sibling tools like get-element-dimensions or get-element-styles, leaving ambiguity about what 'properties and state information' specifically includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools include other element inspection tools (e.g., get-element-html, get-element-styles), and the description lacks any context about preferred use cases or limitations.
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?
With no annotations, the description carries the full burden. It only states 'retrieves style information' without disclosing whether it returns computed styles, any side effects, or performance implications. Minimal behavioral context.
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, but it lacks essential details like return format or usage context. It is front-loaded but incomplete.
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 is provided, and the description does not explain the return format (e.g., a map of property to value). For a simple retrieval tool, this omission is notable and reduces 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?
Input schema covers both parameters with descriptions and examples (e.g., 'color', 'fontSize'). The description adds no extra meaning beyond the schema, so 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 ('retrieves') and resource ('style information of a specific element'). It distinguishes from sibling tools like get-element-properties or get-element-dimensions by focusing on styles, though it doesn't explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get-element-dimensions or get-element-properties. The description lacks context about preferred scenarios 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?
No annotations are provided, so the description carries full responsibility. It only states 'Retrieves recent HMR events' but omits behavioral details like whether it is read-only, side effects, rate limits, pagination behavior, or what 'recent' means. The parameter 'limit' suggests a subset, but no further context is given.
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. It is front-loaded with the verb and resource, and every word contributes meaning. No wasted text.
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 the low complexity (one parameter, no output schema), the description is minimal. It lacks details about what HMR events are, typical usage, default limits, and return format. The agent needs more context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'limit', which already has a clear description ('Maximum number of events to return'). The tool description adds no additional meaning beyond what the schema provides, so the baseline score 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?
The description 'Retrieves recent HMR events' clearly states the action (retrieves) and resource (HMR events). The term 'recent' adds a temporal qualifier, distinguishing it from a generic 'get events' tool. Sibling tools focus on browser actions, so this tool's purpose is distinct and 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 provided on when to use this tool versus alternatives. The description does not mention typical scenarios, prerequisites, or limitations. The agent has no context for deciding between this and sibling tools.
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?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It fails to mention any side effects, output format, or access requirements, leaving the agent uninformed.
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 but lacks substance. It is under-specified rather than concise, failing to earn its place with useful 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?
Given no output schema and missing annotations, the description is grossly incomplete. It does not explain return values or behavior for a tool that likely provides instructional content.
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 enum descriptions, so baseline is 3. The description adds no meaning beyond the schema, but does not contradict it.
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 'Description of how to use the server' is a tautology that restates the tool name without specifying a verb or resource. It does not clarify what the tool actually does (e.g., returns instructions or documentation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description is too vague to infer appropriate usage context.
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 given; the description simply states the tool lists instances, which is straightforward and non-contradictory. However, it adds no extra behavioral context beyond the name.
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 unnecessary words.
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?
While the description clearly states the tool lists active browsers, it does not mention optional filtering or statistics parameters, and there is no output schema to clarify return format. Given the simplicity, it is adequate but could be more 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?
Schema coverage is 100% for parameters, each with a description. The tool description does not add any additional meaning beyond what is already 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 'Lists all active browser instances' uses a specific verb and resource, clearly distinguishing from sibling tools like start-browser, close-browser, and browser-evaluate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to filter versus list all. There is no mentioning of when not to use it.
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?
With no annotations, the description carries the full burden. It does not disclose whether the tool blocks, what it returns, permissions needed, or side effects. The agent is left without key behavioral context.
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 that efficiently conveys the core purpose. While it could include more detail, it avoids verbosity and is well-structured.
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 parameters and no output schema, the description is minimally adequate. It lacks details about return values and default behavior, but the structure and schema partially compensate.
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 description adds no extra meaning beyond the schema. The baseline of 3 is appropriate as the description neither detracts nor adds significant value.
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'), and the context ('in the browser for a specified duration'). It effectively distinguishes the tool from siblings like 'capture-screenshot' or 'get-console-logs' which focus on different aspects of browser interaction.
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. There is no mention of prerequisites, when not to use, or how it compares to sibling tools like 'execute-browser-commands' or 'get-hmr-events'.
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?
With no annotations, the description must disclose behavioral traits. It only states that it creates a new browser context with a unique ID, but fails to mention potential side effects, permissions, or resource limits.
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 wasted words. It is front-loaded with the core purpose. Slightly more detail could be added without harming 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?
Despite having 7 parameters and no output schema, the description is extremely brief. It does not explain the return value, lifecycle of the browser context, or how this tool fits with siblings.
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 schema already describes each parameter. The description adds no extra meaning beyond what is in the schema, earning a baseline score 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 clearly states the verb 'creates' and the resource 'browser context', and mentions the auto-generated unique ID, distinguishing it from other browser tools like close-browser or list-browsers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., execute-browser-commands). There are no explicit when-to-use or when-not-to-use instructions.
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.
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-browserEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Coding agents from Claude Code, Cursor and Codex claim jobs and lock files on one shared board.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ESnark/blowback'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
