Skip to main content
Glama

chrome_page_load_resource_pipeline

Read-onlyIdempotent

Drill into a Chrome page-load resource URL to join lifecycle and request spans with script, style, and layout signals for detailed analysis.

Instructions

Drill into one Chrome page-load resource URL and join lifecycle/request spans with script/style/layout signals. Use after chrome_page_load_resource_summary with example_slice_id or url_substring. Returns timing facts, match evidence, resource ends, primary/detail slice evidence (detail is not a root-cause claim), URL/ancestor-correlated resource result source/hit, machine-id sets, incomplete count, and evidence_boundary. Parameters: URL seed required; optional window filters, url_grouping, limit default 30, max_string_len.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoOptional max rows to return. Defaults to 30 and is capped at 5000. Must be > 0 when set.
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. ANDs with any page-load window.
start_ts_nsNoOptional raw trace timestamp lower bound in nanoseconds. ANDs with any page-load window.
page_load_idNoOptional page-load id used to scope resources/scripts to one navigation phase. Matches `chrome_page_loads.id`. Mutually exclusive with `navigation_id`. If set without `phase`, defaults to `navigation_to_fcp`.
url_groupingNoURL grouping strategy. Defaults to full URL; use without_query to merge signed/nonce query variants of the same endpoint.
navigation_idNoOptional Chrome navigation id used to scope resources/scripts 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`.
url_substringNoOptional URL substring to drill into, e.g. "main.js" or "qianwen-web-desktop/2.3.401/js/main.js". Matches against URL-bearing resource and script slices with SQL INSTR, not LIKE wildcards.
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.
example_slice_idNoOptional resource-summary/hotspot `example_slice_id`; when provided the tool derives that slice's URL and drills into matching URL rows.
Behavior5/5

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

Description lists return fields (timing facts, match evidence, etc.) and notes that detail is not a root-cause claim, adding transparency beyond annotations that already mark readOnly and idempotent. No contradictions.

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?

Description is a single paragraph with multiple sentences, front-loaded with purpose and usage. Could be more concise but avoids unnecessary fluff.

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

Completeness4/5

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

Given 11 parameters and no output schema, the description covers what the tool returns and key parameter guidance. It provides sufficient context for an agent to invoke correctly, though some return details could be more structured.

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%, so the schema fully documents parameters. The description provides a summary but no additional meaning beyond the schema. Minor confusion about 'URL seed' not matching parameter names.

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?

Description clearly states the tool drills into a Chrome page-load resource URL and joins lifecycle/request spans with signals. It specifies the verb 'drill' and the resource, and distinguishes from siblings by positioning as a deeper analysis after chrome_page_load_resource_summary.

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 advises using after chrome_page_load_resource_summary with example_slice_id or url_substring, providing clear context and alternatives. No further when-not-to-use needed given the specificity.

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