Skip to main content
Glama
andresolbach

nodriver-mcp-server

by andresolbach
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Start performance trace

performance_start_trace

Record a Chrome performance trace of page load or interaction, capturing rendering, scripting, loading, screenshots, and V8 CPU. Optionally save raw trace JSON to a file for DevTools analysis.

Instructions

Record a Chrome performance trace of page load or interaction.

Captures the same DevTools timeline categories the Performance panel uses: rendering, scripting, loading, screenshots and the V8 CPU profile.

With the defaults (reload + auto_stop) this is one self-contained call that reloads, records for ~5s and returns. Only one trace can run at a time.

Pass file_path to keep the data — without it you get just an event count, which confirms the trace ran but says nothing about what it measured. The output is raw trace JSON: load it via DevTools -> Performance -> Load profile.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reloadNoReload the page after starting the trace so the recording covers page load. Default true, which is what you want for load performance; set false to profile the page as it currently stands.
browserNoWhich browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.default
auto_stopNoRecord for about 5 seconds, then stop and return the result in this same call. Default true. Set false to control the window yourself and end it with performance_stop_trace.
file_pathNoWrite the raw trace JSON to this local path. Omit to get only the collected event count back.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.0
    • addedInput schema / properties / browser
      Added value: +{
+  "default": "default",
+  "description": "Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.",
+  "type": "string"
+}
  2. First observedv1.7.2

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the sparse annotations (readOnlyHint: false, destructiveHint: false) by disclosing captured timeline categories, the ~5s recording window, the single-trace-at-a-time constraint, and the output behavior (event count vs raw JSON). This is rich, useful behavioral context that the annotations do not provide, and there is no contradiction.

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

Conciseness5/5

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

The description is tightly structured: an opening purpose sentence, a short list of captured categories, a paragraph on default behavior and concurrency, and a note about file_path and output format. Every sentence earns its place; there is no fluff or repetition of schema details.

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?

Given four optional parameters, an output schema, and the presence of a sibling performance_stop_trace, this description is complete: it covers trace content, default timing, concurrency limits, file output behavior, and how to load the result. An agent has everything needed to invoke the tool correctly and interpret its result.

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 100%, so the baseline is 3. The description adds meaning beyond the schema by explicitly explaining the consequences of passing file_path ('keep the data' vs 'just an event count') and by reinforcing the meaning of the defaults (reload + auto_stop) in context. That extra guidance justifies a score above baseline.

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?

The description opens with a specific verb and resource: 'Record a Chrome performance trace of page load or interaction.' It clearly distinguishes this from sibling tools (e.g., performance_stop_trace) by stating it starts the trace, and it lists what the trace captures. An agent can tell exactly what this tool does without opening the schema.

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

Usage Guidelines4/5

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

The description gives clear context on when to use the tool: for profiling page load or interaction, and it explains the default self-contained behavior (reload + auto_stop) plus the option to pass file_path to keep data. It doesn't explicitly name alternatives or state when not to use it, but the usage context is strong enough that an agent would not confuse it with other tools.

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

Deploy Server

Other Tools