Browser Session MCP

Overview Schema Source Related Servers Discussions Admin

stop_profiling

Destructive

Stop the CPU profiler, save a .cpuprofile, and return long tasks, top scripts, functions, and self/total times to identify page performance culprits.

Instructions

Stop the CPU profiler started by start_profiling, save a .cpuprofile under $STATE_DIR/logs//profiles/ (its path is in the result; open it as a flame graph in the DevTools Performance panel or speedscope.app) and return the culprits: long tasks (>=50ms) split into JS vs browser-native (parse/style/layout) vs GC time with their top scripts, top JS functions and heaviest JS stack, top functions by self and total time (with url:line:col), and self time per script. Pass the same tabIndex given to start_profiling. If page JS is hung, the renderer can't answer until it yields, so after terminateAfterMs the running script is terminated to get the profile out (terminated in the result says so); set it to 0 to never terminate. top caps each ranked list, so raise it when the culprit isn't in the first 15, and keep timeout a few seconds above terminateAfterMs so a large profile has time to transfer. The file is deleted with the session by close_browser_session. Fails if start_profiling wasn't called on that tab.

Input Schema

Name	Required	Description
`top`	No	How many entries to return in each ranked list. Default 15.
`timeout`	No	Milliseconds the whole stop call may take before failing. Default 30000.
`tabIndex`	No	The tab passed to start_profiling, by its 0-based list_pages index. Default: the active tab.
`sessionId`	Yes	The id returned by open_browser_session. Errors if no open session has it.
`terminateAfterMs`	No	Milliseconds to wait for hung page JS before terminating it; 0 never terminates. Default 5000.

Output Schema

Name	Required	Description
`path`	Yes	Where the .cpuprofile was saved.
`busyMs`	Yes
`samples`	Yes
`topSelf`	Yes
`topTotal`	Yes
`longTasks`	Yes
`durationMs`	Yes
`terminated`	Yes	Whether hung page JS was terminated to collect the profile.
`topScripts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.5Oct 24, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$defs": {
+    "FnStat": {
+      "properties": {
+        "function": {
+          "type": "string"
+        },
+        "location": {
+          "type": "string"
+        },
+        "ms": {
+          "format": "double",
+          "type": "number"
+        },
+        "percent": {
+          "format": "double",
+          "type": "number"
+        }
+      },
+      "required": [
+        "function",
+        "location",
+        "ms",
+        "percent"
+      ],
+      "type": "object"
+    },
+    "LongTask": {
+      "properties": {
+        "durationMs": {
+          "format": "double",
+          "type": "number"
+        },
+        "gcMs": {
+          "format": "double",
+          "type": "number"
+        },
+        "nativeMs": {
+          "description": "Browser-native work V8 can't attribute to a script: parsing, style,\nlayout, paint. A task dominated by this is layout/DOM churn, not one\nslow function.",
+          "format": "double",
+          "type": "number"
+        },
+        "stack": {
+          "description": "Stack of the heaviest JS frame, innermost first.",
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "startMs": {
+          "description": "Offset from profile start.",
+          "format": "double",
+          "type": "number"
+        },
+        "topJs": {
+          "description": "JS functions with the most self time in this task (`percent` is of the\ntask).",
+          "items": {
+            "$ref": "#/$defs/FnStat"
+          },
+          "type": "array"
+        },
+        "topScripts": {
+          "description": "Scripts with the most self time in this task (`percent` is of the\ntask). Usually the clearest culprit: a task's self time is often spread\nthin across many small functions of one script.",
+          "items": {
+            "$ref": "#/$defs/ScriptStat"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "startMs",
+        "durationMs",
+        "nativeMs",
+        "gcMs",
+        "topJs",
+        "topScripts",
+        "stack"
+      ],
+      "type": "object"
+    },
+    "ScriptStat": {
+      "properties": {
+        "percent": {
+          "format": "double",
+          "type": "number"
+        },
+        "selfMs": {
+          "format": "double",
+          "type": "number"
+        },
+        "url": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "url",
+        "selfMs",
+        "percent"
+      ],
+      "type": "object"
+    }
+  },
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "busyMs": {
+      "format": "double",
+      "type": "number"
+    },
+    "durationMs": {
+      "format": "double",
+      "type": "number"
+    },
+    "longTasks": {
+      "items": {
+        "$ref": "#/$defs/LongTask"
+      },
+      "type": "array"
+    },
+    "path": {
+      "description": "Where the .cpuprofile was saved.",
+      "type": "string"
+    },
+    "samples": {
+      "format": "uint",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "terminated": {
+      "description": "Whether hung page JS was terminated to collect the profile.",
+      "type": "boolean"
+    },
+    "topScripts": {
+      "items": {
+        "$ref": "#/$defs/ScriptStat"
+      },
+      "type": "array"
+    },
+    "topSelf": {
+      "items": {
+        "$ref": "#/$defs/FnStat"
+      },
+      "type": "array"
+    },
+    "topTotal": {
+      "items": {
+        "$ref": "#/$defs/FnStat"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "durationMs",
+    "busyMs",
+    "samples",
+    "topSelf",
+    "topTotal",
+    "topScripts",
+    "longTasks",
+    "path",
+    "terminated"
+  ],
+  "type": "object"
+}

Changed5 schema fields changedOct 23, 2026

addedInput schema / properties / sessionId / description

Added value: +"The id returned by open_browser_session. Errors if no open session has it."

addedInput schema / properties / tabIndex / description

Added value: +"The tab passed to start_profiling, by its 0-based list_pages index. Default: the active tab."

addedInput schema / properties / terminateAfterMs / description

Added value: +"Milliseconds to wait for hung page JS before terminating it; 0 never terminates. Default 5000."

addedInput schema / properties / timeout / description

Added value: +"Milliseconds the whole stop call may take before failing. Default 30000."

addedInput schema / properties / top / description

Added value: +"How many entries to return in each ranked list. Default 15."

First observedv0.1.2Oct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond annotations by explaining that a .cpuprofile is saved, where it lives, how to open it, what analysis is returned, and that hung page JS may be terminated after terminateAfterMs. It also discloses lifecycle behavior: the file is deleted with the session by close_browser_session, which is important given the destructive annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and the rest is dense but mostly useful. It is longer than ideal as a single paragraph, but every sentence carries operational information for a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex profiling tool with an output schema, annotations, and five parameters, the description is complete enough to call correctly. It covers prerequisites, side effects, output location, result contents, failure conditions, parameter interactions, and session-bound file lifecycle.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3. The description adds meaningful semantic detail beyond the schema: tabIndex must match start_profiling, top caps each ranked list, terminateAfterMs of 0 never terminates, and timeout should be a few seconds above terminateAfterMs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: stop the CPU profiler started by start_profiling, and describes the saved .cpuprofile plus the returned culprit analysis. It is clearly distinguishable from sibling tools like start_profiling and close_browser_session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use it after start_profiling, requires passing the same tabIndex, and fails if start_profiling was not called on that tab. It also gives practical guidance for terminateAfterMs, top, and timeout, including when to raise `top` and how to set `timeout` relative to `terminateAfterMs`.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.