Skip to main content
Glama

chrome_startup_summary

Read-onlyIdempotent

Summarize Chrome startup events with launch cause and duration to analyze time to first visible content for cold starts.

Instructions

Summarize Chrome browser startup events: id, name, launch_cause, startup_duration_ms (first_visible_content_ts - startup_begin_ts), browser_upid. Read-only.

Use when: measuring time-to-first-visible-content for cold starts, comparing launch causes (NEW_WINDOW vs CMD_LINE vs RESTORE_SESSION), regressing startup performance.

Don't use for: non-Chrome traces (will error). Browser-process work during steady state is covered by chrome_main_thread_hotspots.

Parameters: optional limit (default 100, capped at 5000) and max_string_len. Operates on the loaded trace.

Output: metadata-first JSON; row_count exact; truncated=true means more rows exist; string_truncated=true means shortened text.

Empty result: trace started after the browser was already running (most cases — startup is captured only when tracing began before launch).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoOptional max rows to return. Defaults to 100 and is capped at 5000. Must be > 0 when set; accepts both numbers and numeric strings.
max_string_lenNoOptional per-string-cell character cap applied to returned Chrome-tool rows only. Unset preserves full strings for precision; accepts both numbers and numeric strings. Must be > 0 when set.
Behavior4/5

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

Annotations already declare readOnlyHint=true, etc. The description reinforces 'Read-only' and adds details: empty result scenario (trace started after browser running), truncation flags (truncated, string_truncated). No contradictions; description adds context beyond annotations.

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?

Description is front-loaded with summary, then use cases, exclusions, parameters, output format, and edge cases—all in a few well-organized paragraphs with no wasted words.

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?

No output schema, but description explains output structure (metadata-first JSON, row_count, truncated flags) and handles empty result scenario. Fully adequate for a read-only query tool with high annotation coverage.

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 coverage is 100% with clear descriptions for limit and max_string_len. The description restates defaults and caps but adds minimal new meaning beyond the schema, so baseline 3 is appropriate.

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 the tool summarizes Chrome startup events with a specific verb ('Summarize') and resource ('Chrome browser startup events'), listing returned fields. It differentiates from sibling tools like `chrome_main_thread_hotspots` by focusing on startup vs steady-state.

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 states when to use (measuring time-to-first-visible-content, comparing launch causes, regressing performance) and when not to use (non-Chrome traces, steady-state; references sibling `chrome_main_thread_hotspots` as alternative).

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