Skip to main content
Glama

chrome_main_thread_hotspots

Read-onlyIdempotent

Identify the longest Chrome main-thread tasks causing jank by wall duration, CPU overlap, and thread time. Filter by process, page load phase, or time window to pinpoint scroll or load stalls.

Instructions

Top Chrome main-thread tasks by wall duration: id, ts, name, task_type, thread_name, process_name, upid, pid, nullable machine_id, dur_ms, overlap_dur_ms, full_task_cpu_pct/full_task_thread_dur_ms, overlap_cpu_pct/overlap_thread_dur_ms; legacy cpu_pct/thread_dur_ms are full-task. Uses chrome.tasks, thread.is_main_thread = 1, and Chrome's Cr*Main fallback. Pass a returned id to slice_descendants_breakdown for child-slice breakdowns.

Use when: investigating responsiveness, scroll/load stalls, CPU vs wall time, or one renderer.

Don't use for: non-Chrome traces (will error). For background (non-main) thread tasks, drop to execute_sql against chrome.tasks directly.

Parameters (all optional):

  • process_name / pid / machine_id / upid: scope to one process/type. Prefer upid; add machine_id to disambiguate multi-machine pids. All filters AND.

  • page_load_id / navigation_id / phase: scope to a page-load window. IDs match chrome_page_loads.id and .navigation_id respectively and are mutually exclusive. phase: navigation_to_fcp, navigation_to_load, dcl_to_fcp, fcp_to_load. If an id is set without phase, defaults to navigation_to_fcp; phase-only uses the latest page load.

  • start_ts_ns / end_ts_ns: raw trace timestamp bounds in nanoseconds (end_ts_ns exclusive); aliases start_ts / end_ts are accepted; intersect page-load windows. overlap_dur_ms is clipped to that window.

  • min_dur_ms: minimum full-task duration, or clipped overlap duration when a window is set. Defaults to 16 ms. Pass 0 for all positive-overlap tasks.

  • limit: max rows (default 100, capped at 5000). Must be > 0 if set.

  • max_string_len: optional cap for returned string cells. Unset preserves full strings for precision. Must be > 0 if set.

Output: metadata-first JSON preserving columns / rows; truncated=true means an extra-row probe found more rows; string_truncated=true means cell text was shortened.

Empty result: no detected main-thread tasks exceeded min_dur_ms at the selected process/window threshold, or the trace uses non-standard main-thread names outside the Cr*Main fallback.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_ts_nsNoOptional raw trace timestamp upper bound in nanoseconds, exclusive. This uses the same unit as the returned `ts` column. ANDs with any page-load window.
limitNoOptional max rows to return. Defaults to 100 and is capped at 5000 to match `execute_sql`. Lower values keep responses short; higher values surface long tails of mid-duration tasks. Accepts both numbers and numeric strings.
machine_idNoOptional machine id filter for multi-machine traces when the trace schema has `process.machine_id`. ANDs with pid/process filters and disambiguates same pid values on different machines. Accepts numbers and numeric strings.
max_string_lenNoOptional per-string-cell character cap applied to returned rows only. Unset preserves full strings for precision; accepts both numbers and numeric strings. Must be > 0 when set.
min_dur_msNoOptional minimum task duration in milliseconds. Defaults to 16 ms (one 60 Hz frame budget). Pass 0 to see ALL main-thread tasks; raise to e.g. 33 (30 Hz) or 100 to focus on the worst stutters. Must be a finite non-negative number. Accepts both numbers and numeric strings.
navigation_idNoOptional Chrome navigation id used to scope tasks to one navigation phase. Matches `chrome_page_loads.navigation_id`. Mutually exclusive with `page_load_id`. If set without `phase`, defaults to `navigation_to_fcp`.
page_load_idNoOptional page-load id used to scope tasks to one navigation phase. Matches `chrome_page_loads.id`. Mutually exclusive with `navigation_id`. If set without `phase`, defaults to `navigation_to_fcp`.
phaseNoOptional page-load phase window. If set without `page_load_id` or `navigation_id`, uses the latest page load in the trace. Values: navigation_to_fcp, navigation_to_load, dcl_to_fcp, fcp_to_load.
pidNoOptional pid filter — the OS-level process ID (visible in Task Manager). Get pid from `list_processes`. ANDs with the other filters when set. Note: pids can be recycled within a long trace; prefer `upid` when precision matters. Accepts both numbers and numeric strings.
process_nameNoOptional process-name filter (e.g. "Renderer", "Browser", "GPU Process"). Useful to scope to one process type without picking a specific instance.
start_ts_nsNoOptional raw trace timestamp lower bound in nanoseconds. This uses the same unit as the returned `ts` column. ANDs with any page-load window.
upidNoOptional upid filter — the trace-internal Unique Process ID assigned by trace_processor (also from `list_processes`). Always uniquely identifies one process within a trace, even if the OS recycled its pid. Use this to disambiguate same-named or pid-recycled processes; ANDs with the other filters when set. Accepts both numbers and numeric strings.
Behavior5/5

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

The description adds significant behavioral context beyond the annotations, including details about default thresholds (16 ms min_dur_ms, limit 100), how filters are ANDed, the clipping of overlap_dur, the fallback for main-thread identification, and explanation of empty results. It also describes output properties like truncated and string_truncated. This fully informs the agent about the tool's behavior.

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 well-structured with clear sections: output overview, usage guidelines, parameter details, and output format. It is front-loaded with the core purpose. However, it is somewhat verbose, especially in parameter descriptions that repeat some schema information. Still, for a complex tool with 12 parameters, the verbosity is justified.

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 the tool has no output schema and 12 parameters, the description covers all necessary aspects: output columns, parameter interactions, defaults, edge cases (empty results, truncation), and error conditions (non-Chrome traces). It provides sufficient context for an agent to invoke the tool correctly without needing additional documentation.

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 baseline is 3. The description adds valuable semantics: explaining mutual exclusivity of page_load_id and navigation_id, default phase behavior, interactions between start_ts/end_ts and page-load windows, and numeric string acceptance. It clarifies defaults and valid ranges, going beyond the schema's descriptions.

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 clearly states that it returns 'Top Chrome main-thread tasks by wall duration' and lists output columns. It explicitly distinguishes from siblings by focusing on main-thread tasks and mentioning the use of `chrome.tasks` and `thread.is_main_thread=1`. The purpose is specific and unambiguous.

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?

The description provides explicit usage guidance: 'Use when: investigating responsiveness, scroll/load stalls, CPU vs wall time, or one renderer.' It also states when not to use it ('Don't use for: non-Chrome traces') and directs to an alternative ('For background thread tasks, drop to `execute_sql`'). Additionally, it suggests chaining to `slice_descendants_breakdown` for child-slice breakdowns.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tooluse-labs/perfetto-mcp-rs'

If you have feedback or need assistance with the MCP directory API, please join our Discord server