devtools-fleet-mcp

Overview Schema Source Related Servers Discussions Admin

performance_start_trace

Start a performance trace on the target webpage. Use to find frontend performance issues, Core Web Vitals (LCP, INP, CLS), and improve page load speed.

Instructions

Start a performance trace on the target webpage. Use to find frontend performance issues, Core Web Vitals (LCP, INP, CLS), and improve page load speed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pageId": "<pageId>"
    },
    "name": "performance_start_trace"
  }
}

Input Schema

Name	Required	Description
`pageId`	Yes	Targets a specific page by ID.
`reload`	No	Determines if, once tracing has started, the target page should be automatically reloaded. Navigate the page to the right URL using the navigate_page tool BEFORE starting the trace if reload or autoStop is set to true.
`autoStop`	No	Determines if the trace recording should be automatically stopped.
`filePath`	No	The absolute file path, or a file path relative to the current working directory, to save the raw trace data. For example, trace.json.gz (compressed) or trace.json (uncompressed).
`ignoreCache`	No	Whether to bypass the HTTP cache when reloading the page, to measure a cold page load. Only applies if reload is true.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Oct 23, 2026

changedInput schema / additionalProperties
```
Previous value: -{}New value: +false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Whether to bypass the HTTP cache when reloading the page, to measure a cold page load. Only applies if reload is true.",
+  "type": "boolean"
+}

First observedv0.1.0Oct 1, 2026

TDQS

A3.5/5.0

Behavior3/5

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

readOnlyHint=false is the only annotation, so the agent knows this is not a pure read, but the description never says the trace keeps recording until performance_stop_trace is called or that a file artifact may be written. The schema descriptions carry the reload/autoStop/cache nuances, which partially compensates.

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?

Two tightly packed sentences with the action front-loaded and the diagnostic value second; no filler.

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

Completeness3/5

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

For a stateful tracing tool with no output schema and only a single loose annotation, the description omits the essential lifecycle (trace runs until stopped, analyze with performance_analyze_insight). An agent could call it but might not know what to do next.

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

Parameters3/5

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

Schema description coverage is 100% and each parameter is documented at the schema level, so baseline 3 applies. The description adds no parameter-level meaning beyond that.

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

Purpose4/5

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

States a clear verb+resource ('Start a performance trace on the target webpage') and adds the diagnostic intent (frontend performance, Core Web Vitals). It doesn't distinguish itself from the sibling lighthouse_audit, which plausibly serves a similar diagnostic role, so 4 rather than 5.

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

Usage Guidelines3/5

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

'Use to find frontend performance issues, Core Web Vitals (LCP, INP, CLS)' gives implied usage context, but there is no explicit when-not guidance and no mention of the sibling alternatives (lighthouse_audit, performance_analyze_insight) or of the required stop step.

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