Skip to main content
Glama

chrome_main_thread_hotspots

Read-onlyIdempotent

Identify top Chrome main-thread tasks causing jank or slow load by wall duration, with filtering by process, page load phase, and duration threshold.

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
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.
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.
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.
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.
trace_idNoOptional trace id returned by `load_trace`. Omit to use the active trace.
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.
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.
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.
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.
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`.
process_nameNoOptional process-name filter (e.g. "Renderer", "Browser", "GPU Process"). Useful to scope to one process type without picking a specific instance.
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`.
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.
Behavior5/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detailed behavioral context: query sources, fallback for main-thread detection, default min_dur_ms of 16ms, output format with truncation flags, and empty result semantics. No contradiction with annotations.

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 long but well-structured with sections for usage, parameter groups, output format, and empty result. Every sentence adds value for a complex tool, though slight verbosity could be trimmed. Still appropriate for the complexity.

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 13 parameters, no output schema, and rich annotations, the description covers all aspects: usage context, parameter details, output format (columns/rows, metadata, truncation), and empty result explanation. It is fully complete for an agent to use correctly.

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

Parameters5/5

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

Schema description coverage is 100% (baseline 3), but the description adds substantial meaning beyond the schema: explains defaults, mutual exclusivity of page_load_id/navigation_id, AND logic for filters, and relationships like `phase` defaults. This is exceptionally thorough parameter documentation.

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 it retrieves 'Top Chrome main-thread tasks by wall duration', lists columns, and distinguishes from sibling tools like `execute_sql` and `slice_descendants_breakdown`. The purpose is specific and differentiated.

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 'Use when' (responsiveness, stutters) and 'Don't use for' (non-Chrome traces, background threads) guidance, and suggests alternatives like `execute_sql` for non-main-thread tasks. This is excellent usage guidance.

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