Enables remote debugging, performance analysis, and memory profiling of web applications running in Chrome or Chromium browsers via the Chrome DevTools Protocol.
Provides tools for generating Lighthouse-style reports to analyze web page performance, accessibility, best practices, and SEO metrics.
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., "@Puppeteer Debugger MCP Server take a screenshot and check for console errors on https://example.com"
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.
一个基于 Puppeteer 和 Chrome DevTools Protocol (CDP) 的 MCP Server 插件，支持通过持久化浏览器连接进行网页调试、性能分析和内存检测。
Console 异常检查：监听和收集 Console 错误、警告和日志
元素状态检查：检查 DOM 元素的属性、样式、可见性和交互性
缓存状态检查：获取 LocalStorage、SessionStorage、Cookies 和 IndexedDB 状态
性能数据获取：收集 Performance Timeline 和页面加载指标
内存堆栈分析：获取堆快照、分析内存使用、跟踪对象分配、检测内存泄漏
持久化连接：浏览器实例在 Server 启动时创建，保持运行直到 Server 关闭，提高性能
Related MCP server: MCP Browser Logger
Node.js 20 或更高版本
Chrome 或 Chromium 浏览器
在 MCP 客户端（如 Cursor、Claude Desktop 等）的配置文件中添加以下配置：
{
"mcpServers": {
"puppeteer-debugger-mcp": {
"command": "npx",
"args": ["-y", "@aliex7664/puppeteer-debugger-mcp@latest"]
}
}
}配置完成后，重启 MCP 客户端即可使用。npx 会自动下载并运行最新版本的包，无需手动安装。
导航到指定 URL。
参数：
url (string, 必需): 要导航到的 URL
示例：
{
"name": "navigate",
"arguments": {
"url": "https://example.com"
}
}获取 Console 异常和日志。
参数：
url (string, 可选): 页面 URL，如果未提供则使用当前页面
level (string, 可选): 日志级别过滤 (error | warning | all)，默认为 all
示例：
{
"name": "get_console_errors",
"arguments": {
"url": "https://example.com",
"level": "error"
}
}检查元素状态（属性、样式、可见性等）。
参数：
selector (string, 必需): CSS 选择器
url (string, 可选): 页面 URL
示例：
{
"name": "check_element",
"arguments": {
"selector": "#my-button",
"url": "https://example.com"
}
}获取缓存状态（LocalStorage、SessionStorage、Cookies、IndexedDB）。
参数：
url (string, 可选): 页面 URL
示例：
{
"name": "get_cache_status",
"arguments": {
"url": "https://example.com"
}
}获取性能数据（Performance Timeline、页面加载指标）。
参数：
url (string, 可选): 页面 URL
示例：
{
"name": "get_performance",
"arguments": {
"url": "https://example.com"
}
}获取堆快照。
参数：
url (string, 可选): 页面 URL
topN (number, 可选): Top N（构造函数/节点）数量，默认 20
collectGarbage (boolean, 可选): 采集前是否触发 GC，默认 false
maxSnapshotBytes (number, 可选): raw snapshot 采集最大字节数，默认 200MB（超出将截断并跳过解析）
maxParseBytes (number, 可选): JSON.parse 解析最大字节数，默认 50MB（超出将跳过解析）
export (object, 可选): raw snapshot 导出选项
mode ('none' | 'file' | 'inline' | 'both', 可选): 导出方式，默认 none
filePath (string, 可选): file/both 模式输出路径；不填则默认写入当前目录下的 ./.heapsnapshot/（服务端会自动创建目录）
maxInlineBytes (number, 可选): inline/both 模式 inline 输出最大字节数（超出截断）
示例：
{
"name": "get_heap_snapshot",
"arguments": {
"url": "https://example.com",
"topN": 20,
"export": {
"mode": "both",
"maxInlineBytes": 65536
}
}
}返回（new shape）：
timestamp: 采集时间戳
summary: 解析摘要（parsed 为 true 时包含 totalNodes/totalSizeBytes/topConstructors/topNodes）
export: raw snapshot 导出结果（file/inline/both）
limitations（可选）: 截断/跳过解析等限制说明
兼容字段（deprecated，计划下个 major 移除）：
totalSize：请迁移到 summary.totalSizeBytes
totalNodes：请迁移到 summary.totalNodes
nodes：为避免响应过大，可能仅返回 TopN 节点（截断）；请迁移到 summary.topNodes（或使用 export.filePath 导出原始快照后再做离线分析）
分析内存使用情况。
参数：
url (string, 可选): 页面 URL
示例：
{
"name": "analyze_memory",
"arguments": {
"url": "https://example.com"
}
}跟踪对象分配。
参数：
url (string, 可选): 页面 URL
duration (number, 可选): 跟踪时长（毫秒），默认 5000
topN (number, 可选): Top N（调用栈）数量，默认 20
collectGarbage (boolean, 可选): 采集前是否触发 GC，默认 false
maxSnapshotBytes (number, 可选): raw profile（带 trace 的 heap snapshot）采集最大字节数，默认 200MB
maxParseBytes (number, 可选): JSON.parse 解析最大字节数，默认 50MB
export (object, 可选): raw profile 导出选项（推荐 file，避免响应过大）
mode (string, 可选): none | file | inline | both
filePath (string, 可选): file/both 模式输出路径（推荐相对路径，如 ./.heapsnapshot/alloc.heapsnapshot）
maxInlineBytes (number, 可选): inline/both 模式 inline 最大字节数（超出截断）
示例：
{
"name": "track_allocations",
"arguments": {
"url": "https://example.com",
"duration": 10000,
"topN": 20,
"export": {
"mode": "file",
"filePath": "./.heapsnapshot/alloc-example.heapsnapshot"
}
}
}截图（辅助调试）。支持智能输出模式，自动根据图片大小选择返回 base64 或保存为文件，改进的全页截图功能可正确处理懒加载内容。
参数：
url (string, 可选): 页面 URL（可选）
fullPage (boolean, 可选): 是否截取整页，默认 false
outputMode (string, 可选): 输出模式，默认 auto
auto：根据图片大小自动选择（小图片返回 base64，大图片保存为文件）
file：始终保存为文件，返回路径
inline：始终返回 base64（仅用于小图片）
filePath (string, 可选): 文件保存路径（file/auto 模式使用，默认：./screenshots/screenshot-{timestamp}-{random}.png）
maxBase64SizeKB (number, 可选): auto 模式阈值（KB，base64 大小，默认 100KB base64 ≈ 75KB 原图）
scrollDelay (number, 可选): 滚动后等待时间（毫秒，用于触发懒加载，默认 1000）
waitForSelector (string, 可选): 等待特定选择器加载（可选）
示例：
基本截图（视口）：
{
"name": "take_screenshot",
"arguments": {
"url": "https://example.com"
}
}全页截图（自动输出模式）：
{
"name": "take_screenshot",
"arguments": {
"url": "https://example.com",
"fullPage": true,
"outputMode": "auto"
}
}保存为文件：
{
"name": "take_screenshot",
"arguments": {
"url": "https://example.com",
"fullPage": true,
"outputMode": "file",
"filePath": "./screenshots/example.png"
}
}返回 base64（小图片）：
{
"name": "take_screenshot",
"arguments": {
"url": "https://example.com",
"outputMode": "inline"
}
}等待特定元素加载后截图：
{
"name": "take_screenshot",
"arguments": {
"url": "https://example.com",
"fullPage": true,
"waitForSelector": ".main-content",
"scrollDelay": 2000
}
}获取 Lighthouse 性能报告（包括性能、可访问性、最佳实践、SEO 等指标）。
参数：
url (string, 可选): 页面 URL（可选）
onlyCategories (string[], 可选): 只分析的类别（可选，如：performance, accessibility, best-practices, seo）
skipAudits (string[], 可选): 跳过的审计项 ID（可选，如：uses-optimized-images, render-blocking-resources）
示例：
{
"name": "get_lighthouse",
"arguments": {
"url": "https://example.com",
"onlyCategories": ["performance", "accessibility"],
"skipAudits": ["uses-optimized-images"]
}
}返回结构：
返回的报告中包含以下字段：
url: 页面 URL
fetchTime: 报告生成时间
userAgent: 用户代理字符串
categories: 类别评分（根据 onlyCategories 参数过滤）
performance: 性能评分
accessibility: 可访问性评分
best-practices: 最佳实践评分
seo: SEO 评分
metrics: 性能指标
firstContentfulPaint: 首次内容绘制时间
largestContentfulPaint: 最大内容绘制时间
totalBlockingTime: 总阻塞时间
cumulativeLayoutShift: 累积布局偏移
speedIndex: 速度指数
timeToInteractive: 可交互时间
firstInputDelay: 首次输入延迟
timeToFirstByte: 首字节时间
opportunities: 优化建议（根据 skipAudits 参数过滤）
diagnostics: 诊断信息（根据 skipAudits 参数过滤）
implementation: 固定为 "approximation"，表示这是基于 Web Vitals 和 CDP 的近似实现
limitations: 限制说明数组，包含以下内容：
"accessibility/best-practices/seo 评分为近似值，非完整审计"
"指标采集基于 Web Vitals 和 CDP，可能与真实 Lighthouse 结果有差异"
"部分审计项可能缺失或不完整"
注意事项：
onlyCategories 参数用于过滤返回的类别，如果未指定则返回所有类别
skipAudits 参数用于跳过特定的审计项，这些审计项不会出现在 opportunities 和 diagnostics 中
返回的评分和指标是基于 Web Vitals 和 CDP 的近似值，可能与真实 Lighthouse 结果有差异
accessibility、best-practices 和 seo 的评分为占位值，仅供参考
// 1. 导航到页面
{
"name": "navigate",
"arguments": {
"url": "https://example.com"
}
}
// 2. 获取 Console 错误
{
"name": "get_console_errors",
"arguments": {
"level": "error"
}
}{
"name": "get_performance",
"arguments": {
"url": "https://example.com"
}
}{
"name": "check_element",
"arguments": {
"selector": "button.submit",
"url": "https://example.com"
}
}// 获取初始堆快照
{
"name": "get_heap_snapshot",
"arguments": {
"url": "https://example.com"
}
}
// 分析内存使用情况
{
"name": "analyze_memory",
"arguments": {
"url": "https://example.com"
}
}
// 跟踪对象分配
{
"name": "track_allocations",
"arguments": {
"url": "https://example.com",
"duration": 10000
}
}// 获取完整的 Lighthouse 报告
{
"name": "get_lighthouse",
"arguments": {
"url": "https://example.com"
}
}
// 只分析性能类别
{
"name": "get_lighthouse",
"arguments": {
"url": "https://example.com",
"onlyCategories": ["performance"]
}
}
// 跳过特定审计项
{
"name": "get_lighthouse",
"arguments": {
"url": "https://example.com",
"skipAudits": ["uses-optimized-images", "render-blocking-resources"]
}
}持久化连接：浏览器实例在 Server 启动时创建，保持运行直到 Server 关闭。
动态 URL：所有工具都支持通过参数传入 URL。如果页面不存在，系统会自动创建新页面并导航到指定 URL。
Chrome 路径：如果系统未安装 Chrome 或 Chromium，或安装路径不在默认位置，可以通过 PUPPETEER_EXECUTABLE_PATH 环境变量指定浏览器路径：
Windows: C:\Program Files\Google\Chrome\Application\chrome.exe
macOS: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
Linux: /usr/bin/google-chrome 或 /usr/bin/chromium-browser
MIT
分析内存使用情况
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 页面 URL（可选） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states a vague action. It does not disclose if it returns data, mutates state, requires permissions, or affects performance. The behavioral impact is unclear.
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 phrase with no wasted words. It is appropriately sized for a simple tool, though slightly too minimal. Still, it earns a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameter, the description is incomplete. It fails to explain the purpose's scope, return value, or any caveats. The agent lacks sufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one optional parameter described. Baseline is 3. Description adds nothing beyond the schema, but also does not detract. No additional meaning provided.
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 '分析内存使用情况' (analyze memory usage) clearly states a specific verb and resource. It is not a tautology and distinguishes from siblings like get_heap_snapshot (snapshot) and track_allocations (tracking). However, it lacks any additional distinction or detail.
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 specify when to use this tool versus siblings like get_heap_snapshot or track_allocations. The agent has no context to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查元素状态（属性、样式、可见性等）
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS 选择器 | |
| url | No | 页面 URL（可选） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool modifies state, requires specific permissions, or handles missing elements. It only states it 'checks' state, which implies read-only but is not explicit.
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 functionality without waste. It could benefit from slightly more detail but remains efficient 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?
Given the tool's simplicity and lack of output schema, the description covers the main use (checking attributes, styles, visibility) but omits return format, error behavior, and any performance implications, leaving some gaps for an AI 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 description coverage is 100% for both parameters. The description adds no additional meaning beyond the schema's own descriptions (CSS selector, optional page URL). 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 the tool's purpose: checking element state including attributes, styles, visibility. It effectively distinguishes from sibling tools which focus on memory, cache, console errors, performance, navigation, screenshots, and allocations.
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 vs alternatives, nor does it mention conditions or prerequisites. It does not reference any sibling tools or suggest when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取缓存状态（LocalStorage、SessionStorage、Cookies、IndexedDB）
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 页面 URL（可选） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden of behavioral disclosure. It does not mention whether the tool is read-only, has side effects, requires permissions, or what happens if the URL parameter is omitted.
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, very concise. It front-loads the main purpose and enumerates cache types, but could be slightly more informative without losing 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?
With no output schema and no annotations, the description should explain return values, behavior with invalid URLs, or scope ('all tabs' vs 'specific page'). The simple one-liner leaves many gaps for a tool that queries browser storage.
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 for the single parameter 'url', describing it as optional. The description adds no extra meaning beyond what the schema already provides, 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 'get' and resource 'cache status', explicitly listing the cache types (LocalStorage, SessionStorage, Cookies, IndexedDB). This distinguishes it from sibling tools like get_heap_snapshot or get_performance.
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 (e.g., get_console_errors, check_element). No context on when it is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 Console 异常和日志
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 页面 URL（可选，如果未提供则使用当前页面） | |
| level | No | 日志级别过滤 | all |
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 the function without mentioning whether it is read-only, whether it clears logs, requires a page to be loaded, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It is appropriately concise for a simple tool, but 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 low complexity (2 parameters, no nested objects, no output schema), the description is minimally adequate. It does not explain the return format or any preconditions, but the parameters are well-defined in the schema.
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%, as both parameters have descriptions. The description adds no additional meaning beyond the schema, meeting the baseline but not exceeding 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 clearly states the tool retrieves console exceptions and logs. The verb 'get' and resource 'console errors/logs' are specific, and sibling tools like 'analyze_memory' or 'take_screenshot' are distinct.
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. There is no mention of prerequisites, expected context, or cases where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取堆快照（建议先让用户选择是否导出 raw snapshot，以及导出方式：none/file/inline/both）
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 页面 URL（可选） | |
| topN | No | Top N（构造函数/节点）数量，默认 20 | |
| collectGarbage | No | 采集前是否触发 GC，默认 false | |
| maxSnapshotBytes | No | raw snapshot 采集最大字节数，默认 200MB | |
| maxParseBytes | No | JSON.parse 解析最大字节数，默认 50MB | |
| export | No | raw snapshot 导出选项（建议先确认导出方式与路径） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action and a user suggestion, omitting details like return type, side effects (e.g., GC trigger), permissions, or performance impact. This is insufficient for a complex 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 a single sentence with a parenthetical, front-loading the core action and key usage note. It is concise and avoids waste, though it could be slightly more 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?
Given the tool's complexity (6 parameters, nested object, no output schema), the description is too brief. It lacks details about return values, process flow, and potential caveats (e.g., size limits). The output schema is missing, so description should 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 coverage is 100%, so parameters are well-documented in the schema. The description adds a high-level usage hint but no additional per-parameter context. Baseline 3 is appropriate as schema does the heavy lifting.
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 a heap snapshot ('获取堆快照'), which is a specific verb+resource. It distinguishes from siblings like 'analyze_memory' by focusing on snapshot export options, though it could be more explicit about the tool's unique role.
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 explicitly advises asking the user about exporting the raw snapshot and the export mode ('建议先让用户选择是否导出 raw snapshot，以及导出方式'), providing a clear when-to-use guideline. However, it does not mention when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 Lighthouse 性能报告（包括性能、可访问性、最佳实践、SEO 等指标）
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 页面 URL（可选） | |
| onlyCategories | No | 只分析的类别（可选，如：performance, accessibility, best-practices, seo） | |
| skipAudits | No | 跳过的审计项 ID（可选，如：uses-optimized-images, render-blocking-resources） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as whether it runs a full audit, potential side effects, or duration. It only states the output is a report.
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. It is concise and front-loaded with the main 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?
Given no output schema, the description should explain return values. It does not mention what happens without a URL or how results are structured. Sibling relationships are unaddressed.
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 parameters are documented. The description adds no additional meaning beyond what the schema already provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a Lighthouse performance report covering multiple metric categories. However, it does not differentiate from sibling tool 'get_performance', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_performance'. The description lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取性能数据（Performance Timeline、页面加载指标）
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 页面 URL（可选） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose side effects, required permissions, or whether it is read-only. The description is minimal and does not explain what happens if url is omitted or what the return format is.
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?
Single sentence that is concise and front-loaded. The parentheses add specific types without clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description provides basic understanding. However, it could be more specific about the data returned or how it relates to sibling tools.
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 has 100% coverage with description for the 'url' parameter. The tool description adds no additional meaning beyond the schema. 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?
Description clearly states it gets performance data and specifies types (Performance Timeline, page load metrics). It is specific and distinct from sibling tools like analyze_memory or get_cache_status, but does not explicitly differentiate from get_lighthouse.
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 like get_lighthouse or analyze_memory. No context about prerequisites or situations where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
截图工具（辅助调试）。支持视口截图和全页截图。建议在使用前询问用户希望的输出方式：如果用户需要直接查看图片，使用 inline 模式返回 base64；如果用户需要保存图片文件，使用 file 或 auto 模式保存为文件。对于全页截图或大图片，强烈建议使用 file/auto 模式避免响应过大。
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 页面 URL（可选） | |
| fullPage | No | 是否截取整页。true 表示截取整个页面（包括需要滚动才能看到的内容），false 表示只截取当前视口可见部分。全页截图会自动触发懒加载内容，确保完整截图。 | |
| outputMode | No | 输出模式（建议在使用前询问用户偏好）： - auto：根据图片大小自动选择（小于阈值返回 base64，大于阈值保存为文件，默认阈值 100KB） - file：始终保存为文件，返回文件路径（适合用户明确需要保存文件的情况） - inline：始终返回 base64 编码的图片数据（适合用户需要直接查看小图片的情况，不推荐用于全页截图，因为会导致响应过大） 选择建议： - 如果用户说"截图"、"保存截图"、"下载截图"等，使用 file 或 auto 模式 - 如果用户说"显示截图"、"查看截图"、"预览截图"等，且图片较小（非全页），可以使用 inline 模式 - 如果用户未明确说明，或进行全页截图，默认使用 auto 模式 - 如果不确定用户需求，建议询问："您希望截图以什么方式返回？1) 保存为文件（推荐，适合大图片） 2) 直接返回图片数据（仅适合小图片）" | auto |
| filePath | No | 文件保存路径（可选，仅在 file/auto 模式时有效）。如果未指定，默认保存到 ./screenshots/screenshot-{timestamp}-{random}.png。可以使用相对路径（相对于 MCP Server 工作目录）或绝对路径。 | |
| maxBase64SizeKB | No | auto 模式阈值（KB，base64 大小，默认 100KB）。当 auto 模式下，如果图片的 base64 大小超过此阈值，会自动保存为文件；否则返回 base64。 | |
| scrollDelay | No | 滚动后等待时间（毫秒，用于触发懒加载，默认 1000） | |
| waitForSelector | No | 等待特定选择器加载（可选，字符串） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully cover behavioral traits. It explains that inline returns base64, file/auto saves to file, and that full-page screenshots may trigger lazy loading. However, it does not mention prerequisites like needing a page to be loaded first.
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 verbose, especially the outputMode section which largely repeats information found in the schema. While organized with bullet points, it could be more concise to improve readability.
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 7 parameters with full schema descriptions, no required parameters, and no output schema, the description offers robust usage guidance and covers decision-making for output modes. However, it could mention what happens when no URL is provided.
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 some context (e.g., asking user for output mode) but much of the parameter guidance is already in the schema descriptions. The added value is limited.
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's a screenshot tool for debugging, supporting viewport and full-page screenshots. It distinguishes itself from sibling tools which have different purposes (memory analysis, element checking, etc.).
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 explicit guidance on when to use each output mode (inline vs file/auto) and recommends asking the user for preference. It also advises against using inline for full-page or large images, and suggests defaulting to auto when uncertain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
跟踪对象分配
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 页面 URL（可选） | |
| duration | No | 跟踪时长（毫秒），默认 5000 | |
| topN | No | Top N（调用栈）数量，默认 20 | |
| collectGarbage | No | 采集前是否触发 GC，默认 false | |
| maxSnapshotBytes | No | raw snapshot 采集最大字节数，默认 200MB | |
| maxParseBytes | No | JSON.parse 解析最大字节数，默认 50MB | |
| export | No | raw profile 导出选项 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only says 'track object allocations' without explaining that it runs for a duration, triggers GC optionally, or produces a summary or snapshot. Key behavioral traits like performance impact or non-destructiveness are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only 4 Chinese characters, which is under-specified. It is not a complete sentence and fails to convey essential information. Conciseness should be achieved without sacrificing clarity; here it is too brief.
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 tool's complexity (7 parameters, nested objects, no output schema), the description is severely lacking. It does not explain return values, typical use cases, or how the tracking integrates with other memory tools. Completely inadequate for an agent to use 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?
The input schema has 100% description coverage for all 7 parameters, including nested export options. Since the schema already provides detailed parameter semantics, the description adds no additional meaning beyond what's in 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 '跟踪对象分配' translates to 'Track object allocations', which states the core action and resource. However, it is a short phrase without elaboration, making it somewhat vague. It barely distinguishes from sibling tools like get_heap_snapshot (which takes a snapshot) and analyze_memory (which analyzes memory), but not explicitly.
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 scenarios or exclusions, leaving the agent without context to decide among sibling tools like get_heap_snapshot or analyze_memory.
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.
v2.3.0analyze_memorycheck_elementget_cache_statusget_console_errorsget_heap_snapshotget_lighthouseget_performancenavigatetake_screenshottrack_allocationsEach tool targets a distinct debugging concern: memory, elements, cache, console, heap, performance, Lighthouse, navigation, screenshots, and allocations. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_memory, check_element, get_cache_status). No deviations or mixed conventions.
With 10 tools, the set is well-scoped for a debugging server. It covers essential debugging operations without being overwhelming or sparse.
The server covers major debugging areas: navigation, inspection, performance, memory, and console. Minor gaps like network request monitoring or DOM interaction are absent, but core debugging workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live browser debugging for AI assistants — DOM, console, network via MCP.
MCP server to assist with JxBrowser development.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
MCP server for understanding Javascript internals from ECMAScript specification.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ALIEX7664/puppeteer-debugger-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
