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.

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.

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.

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.

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.

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.

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

Annotations already indicate the tool is read-only and idempotent. The description adds useful behavioral details about the slice_duration_status meaning and overlap measurement, complementing the annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose, followed by usage guidance and a note on parameters and status. No wasted words, very efficient.

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

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

The description covers purpose, return fields, usage context, key filters, and a behavioral nuance. Given no output schema, it provides enough context for the agent to understand the tool's role and basic output, though more explicit output structure could help.

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

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

Schema coverage is 100% with detailed parameter descriptions. The description summarizes key filters and defaults, adding high-level grouping but not significantly new meaning beyond the schema.

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

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

The description clearly states the tool ranks URL-bearing resource slices in a page-load/raw window. It specifies the verb 'rank', the resource, and the context, and distinguishes from sister tool chrome_page_load_resource_summary by indicating it is used to drill into slow slices after that summary.

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

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

The description explicitly says to use the tool after chrome_page_load_resource_summary to drill into slow URL slices, providing clear sequencing. It also lists key filters, though it does not explicitly state when not to use it.

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

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.

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.

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.

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.

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.

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.

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

Annotations already provide readOnlyHint, idempotentHint, non-destructive. Description adds behavioral context: lists output fields, clarifies 'detail is not a root-cause claim', explains navigation/renderer relation. It goes beyond annotations but could mention more about result interpretation or caveats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is moderately sized (3 sentences) and front-loaded with purpose. Could slightly improve structure (e.g., list fields separately), but effectively conveys essential information without redundancy.

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

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

Given 10 parameters, no output schema, and annotations covering safety, the description is fairly complete. It lists output fields and usage hints. However, without output schema, it could elaborate on fields like max/summed overlap and incomplete_duration_slice_count.

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

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

Input schema has 100% parameter description coverage, so the description does not need to add parameter meaning. It does not provide additional context beyond the schema, maintaining baseline score.

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

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

Description clearly states it provides a URL-level resource summary for a page-load or raw window, using specific verbs and resource. It distinguishes itself from siblings by noting it should be used before chrome_page_load_resource_hotspots.

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

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

Explicitly states 'Use before chrome_page_load_resource_hotspots; rank by max overlap', giving clear ordering guidance. However, it does not detail when to avoid this tool or contrast with other similar tools like chrome_page_load_summary.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it is 'Read-only' and describes the ranking behavior with optional filters, plus mentions empty result meaning. Provides useful operational context beyond safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two paragraphs with core purpose front-loaded, then usage and parameter guidance. It is efficient without being overly verbose. Every sentence adds value, though the parameter list is somewhat redundant with schema.

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

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

Given 13 parameters and no output schema, the description explains output fields (URL, name, totals, etc.) and links to sibling for expansion. It provides sufficient context for a read-only analysis tool, covering what results look like and how to use them.

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

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

Schema coverage is 100%, so baseline is 3. Description repeats some default values (min_total_ms=20) and lists filter types but adds little new detail beyond the schema. Mentions 'Empty result: no matching script groups' which is a minor addition.

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

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

The description clearly states the tool ranks renderer main-thread script groups in a Chrome page-load/raw window, listing specific output fields like URL, name, wall/CPU totals. It distinguishes itself by mentioning 'post-resource JS attribution' and referencing the sibling tool for expansion.

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

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

Explicitly states 'Use when: slow FCP/load needs post-resource JS attribution' and guides to expand `example_slice_id` with `slice_descendants_breakdown`. It also notes that parameters are shared with `chrome_main_thread_hotspots`. Lacks explicit when-not-to-use compared to siblings.

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

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

Description adds context beyond annotations: states read-only, describes output format (metadata-first JSON), mentions row_count and truncated flags, and explains empty result behavior. Annotations already indicate readOnlyHint, but description enriches transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise with 5-6 sentences, each serving a purpose: purpose, read-only, usage, don't-use, parameters, output, empty result. No fluff.

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

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

For a tool with three optional parameters and no output schema, the description covers output structure, edge cases, and usage context thoroughly. Sufficient for an agent to decide and invoke correctly.

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

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

Schema coverage is 100% and includes descriptions for all three parameters. Description reinforces limit (default 100, capped 5000) and max_string_len role. Trace_id is omitted from description but schema covers it well, so value added is moderate.

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

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

The description clearly states the tool summarizes page navigations in a Chrome trace, enumerating specific timings (FCP, LCP, DCL, load). It distinguishes itself from sibling tools like chrome_page_load_resource_hotspots by focusing on top-level navigation summary.

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

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

Explicitly provides when to use (comparing timings), when not to use (non-Chrome traces), and an alternative (execute_sql for sub-event timings). Also recommends preferring this over manual joins.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which the description reinforces ('Read-only'). It adds details like operating on the loaded trace, empty result meaning (clean trace or no scrolls), and output metadata (row_count, truncated flags). 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise yet comprehensive, using clear sections and bullet-like lists. Every sentence adds value, and the structure is front-loaded with key info. No wasted words.

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

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

For a tool with 3 parameters and no output schema, the description thoroughly explains output format, metadata, and edge cases (empty results, truncation). It fully compensates for lack of output schema.

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

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

Schema coverage is 100%; the description adds context beyond the schema, such as default limit (100), cap (5000), and max_string_len purpose. This elevates it above the baseline 3.

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

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

The description clearly states the tool summarizes the worst scroll jank frames from a Chrome trace, listing specific output columns. It distinguishes itself from siblings like `execute_sql` and other Chrome summary tools, providing a specific verb+resource.

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

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

Explicit guidance on when to use (investigating jank, finding regressions) and when not to (non-Chrome traces). Also suggests an alternative (`execute_sql`) for custom filters, leaving no ambiguity.

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

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

Annotations set readOnlyHint=true and idempotentHint=true; the description adds operational details: limit cap (5000), output metadata (row_count, truncated flags), and explains the empty result scenario (trace started after browser launch).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with separate paragraphs for purpose, usage, parameters, output, and edge cases. Every sentence is informative with no redundancy.

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

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

Given the tool's complexity and no output schema, the description fully covers input parameters, output metadata, empty result handling, and trace scope, making it complete for an AI agent to decide to use the tool.

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

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

100% schema coverage means the schema already describes all three parameters with their types, defaults, and constraints. The description mentions limit and max_string_len but adds no additional semantic value beyond what the schema provides.

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

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

The description uses a specific verb ('Summarize') and resource ('Chrome browser startup events'), lists the fields returned, and explicitly distinguishes from sibling tools like chrome_main_thread_hotspots for steady-state analysis.

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

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

Provides explicit use cases (cold start measurement, launch cause comparison, regression analysis) and clear contraindications (non-Chrome traces, steady-state work handled by chrome_main_thread_hotspots).

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description details output format (metadata-first JSON, row_count, truncated, string_truncated) and explains empty results (no interactions captured). No contradictions 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately long but well-structured with sections for output columns, usage, parameters, and output behavior. It front-loads key information but could be slightly more succinct.

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

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

Given no output schema, the description explains output format and status flags adequately. It covers trace_id implicitly by stating 'operates on the loaded trace,' and explains empty results. Slightly more detail on trace_id parameter could be added.

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

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

Description adds minimal value for limit (default/cap) and max_string_len, but schema already covers all three parameters with 100% coverage. The description notes the limit default and cap, confirming schema info.

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

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

The description clearly states it ranks Chrome web content interactions by duration, listing specific columns (id, ts, total_duration_ms, etc.) and explicitly marks itself as read-only. It distinguishes from siblings by noting that filtered interactions can be obtained via execute_sql on the same table.

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

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

Provides explicit use cases (INP analysis, reproducing user-felt latency, finding slow handlers) and exclusions (non-Chrome traces will error). Also offers an alternative approach for filtering by interaction_type, which helps an agent choose correctly.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds important behavioral details: aggregates preferred over raw rows, 5000 row cap, blob rendering as hex, string redaction by server privacy policy, and error handling with hints. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is comprehensive but well-structured: core action first, then usage guidelines, then parameter details, error handling, and references. It is front-loaded with the essential purpose. While long, each sentence adds necessary information for an agent to use the tool correctly.

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

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

Given 8 parameters, no output schema, and the tool's complexity (query language, error modes, privacy redaction), the description covers all key behaviors, constraints, and edge cases. It also provides links to external documentation for details on SQL syntax and stdlib modules.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds value by explaining that `head`/`limit` only trim output, not rewrite SQL; that `sql` can include `INCLUDE PERFETTO MODULE`; and that `summary` defaults to 10 samples. This exceeds the baseline expectation.

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

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

The description clearly states the tool runs a PerfettoSQL query against a loaded trace and returns rows as columnar JSON. It distinguishes itself from sibling tools by explicitly noting that dedicated `chrome_*` tools exist for specific analyses and should be used instead.

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

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

Provides explicit guidance on when to use (composing custom analyses not covered by dedicated tools) and when not to use (for questions answered by `chrome_*` tools or when stdlib modules suffice). Names alternatives like `chrome_*` tools and stdlib modules.

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

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

The description adds significant context beyond annotations: it states the tool is read-only (consistent), explains what data is returned, describes rare outcomes (empty result), and documents error conditions (no trace loaded). Annotations already mark it as read-only and non-destructive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections and front-loaded information. It could be slightly more concise by removing 'Read-only.' since annotations already convey that, but overall it efficiently delivers value.

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

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

Given no output schema, the description thoroughly covers return fields, edge cases, and error scenarios. It fully prepares the agent to use the tool correctly and understand its results.

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

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

The description claims 'Parameters: none — operates on the loaded trace', but the input schema includes an optional 'trace_id' parameter. This is a direct contradiction between description and schema, misleading the agent about available parameters. Despite 100% schema coverage, the description undercuts clarity.

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

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

The description clearly states 'List every process captured in the trace' and enumerates the fields returned. This explicitly identifies the tool's function and scope, distinguishing it from siblings that focus on specific Chrome analyses.

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

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

Explicit guidance on when to use (entry point for Android/Linux, picking pid) and when not to (Chrome traces), with specific alternative tools mentioned (chrome_* tools).

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds important context: no trace required, result format (JSON with fields), and optional filters. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two precise sentences. First sentence states core function and output. Second sentence adds usage context and optional filters. No redundant information.

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

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 format. Covers optional filters and points to a resource for longer guidance. Adequate for selection and invocation.

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

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

Schema description coverage is 100%, and the description enhances each parameter: valid domain values, case-insensitive search scope for query, and constraint for limit. Provides meaning beyond bare schema.

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

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

Description clearly states the tool lists curated PerfettoSQL stdlib modules with specific fields, and its purpose is for choosing an INCLUDE PERFETTO MODULE target. It distinguishes from siblings which are specific analysis tools.

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

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

Explicitly says when to use (choosing INCLUDE PERFETTO MODULE target) and notes that no trace needs to be loaded. Optional filters are mentioned, but no explicit alternatives or when-not-to-use are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint. Adds value by explaining SQLite engine, behavior of pattern parameter hiding internal tables, empty result handling, and error when no trace loaded. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with clear sections (Use when, Don't use for, Parameters, Empty result, Errors). Every sentence adds value, no fluff. Appropriately sized for the tool's complexity.

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

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

Despite no output schema, the description covers return behavior (empty result) and error conditions (no trace loaded). It also explains the underlying SQL engine limitation, making the tool's role clear in the larger system.

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

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

Schema coverage is 100%, so baseline is 3. Description adds meaningful details: pattern is a GLOB filter with examples, trace_id is optional and defaults to active trace. This provides context beyond the schema descriptions.

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

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

The description clearly states 'List tables and views in the loaded trace. Read-only.' It uses a specific verb and resource, and distinguishes itself from siblings like execute_sql and list_stdlib_modules.

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

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

Explicitly states when to use (exploring unfamiliar trace) and when not to use (known stdlib modules, avoid calling tool name in SQL). Mentions alternative execute_sql with INCLUDE PERFETTO MODULE.

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

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

Annotations already indicate safe read-only operation. The description adds behavioral details: case-sensitivity, alias support, error conditions, and the need to call list_tables first. This provides useful 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is compact and well-structured: summary, when/not to use, parameter details, error info. Every sentence earns its place with no redundancy.

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

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

Despite no output schema, the description adequately explains what is returned (columns attributes) and handles error conditions. It also provides prerequisite guidance (call list_tables) and version info for alias, making it complete for the tool's complexity.

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

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

Input schema covers 100% of parameters, but the description adds extra meaning: case-sensitive, no pattern matching, accepts alias 'name'. This exceeds the baseline of 3 for high coverage.

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

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

The description clearly states it shows columns of a table/view with specific attributes (name, type, nullability, primary_key). This distinguishes it from sibling tools like list_tables and execute_sql.

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

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

Explicitly tells when to use (after 'no such column' error) and when not to use (not a SQL function). Provides alternative actions like calling list_tables first and noting stdlib views may need INCLUDE.

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

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

Annotations indicate safe read-only behavior (readOnlyHint, idempotentHint, destructiveHint false). The description adds details on pagination (truncated, has_more), ordering, empty result error pointing to list_processes, and process_counts for same-name fan-out.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections and bullet points. Front-loaded with essential info. Slightly lengthy but every sentence adds value. Could be slightly more concise but overall effective.

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

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

Comprehensive coverage given 5 parameters, no output schema, but rich annotations. Includes usage context, parameter details, behavioral traits (pagination, ordering, empty results), and error handling.

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

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

With 100% schema coverage, baseline is 3. The description adds significant value by explaining parameter trade-offs (upid vs process_name), precedence, accepted types (numeric strings), and pagination usage, exceeding schema documentation.

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

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

The description clearly states the tool lists threads for a specific process or same-named process set, specifying output fields (tid, thread_name, pid, upid, machine_id) and limits. It distinguishes itself from siblings like list_processes and execute_sql.

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

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

Explicit 'Use when' and 'Don't use for' sections with direct references to list_processes and execute_sql, providing clear context and alternatives.

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

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

Annotations already declare idempotent and non-destructive. Description adds valuable context: caching behavior ('cached trace processors make repeat loads cheap'), active default trace management, and error conditions. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with action and output, then uses clear sections for usage, parameters, and errors. Every sentence adds value; no fluff or redundancy.

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

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

Covers return value (routing summaries + trace_ids), error conditions, and behavior with multiple calls. Without an output schema, the description is sufficiently complete for an agent, though more detail on the return structure could help.

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

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

Schema coverage is 100% with descriptions for path and paths. The description adds usage nuance (one vs batch, active default) and caching behavior, which provides extra value beyond the schema. However, the schema already covers format and mutual exclusivity.

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

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

The description clearly states the tool loads Perfetto trace files and provides trace_id handles, distinguishing it from sibling analysis tools which consume loaded traces. The verb 'load' and resource 'local Perfetto trace files' are specific.

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

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

Explicit 'Use when' and 'Don't use for' sections guide the agent to call this first for analysis sessions and avoid live capture. It also explains how other tools use the active trace and how to pass trace_id.

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

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

Annotations indicate read-only and idempotent. The description adds significant behavioral detail: echoes summary_scope, applied_filters, missing_root_ids; explains each column (e.g., do not sum inclusive_total_ms across depths, self_ms clamped at zero, first_ts_ns in raw nanoseconds, incomplete_descendant_count excludes dur<0). Root slices are omitted from summary. These details go 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph but front-loads the purpose and efficiently covers all aspects. Could be slightly improved with bullet points for the list of parameters and return columns, but it is not overly verbose and every sentence adds value.

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

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

No output schema, so the description fully documents the return structure: columns, their meanings, and special handling like clamping and incomplete counts. It also covers optional parameters and the summary metadata. Given the complexity of recursive expansion and many columns, this is complete.

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

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

Schema coverage is 100%, but the description enriches each parameter with defaults and context: limit defaults to 100 capped at 5000, max_depth defaults to 8 and must be >0, min_dur_ms defaults to 1 ms, include_args boolean, max_string_len must be >0 if set. It also notes that slice_ids accepts numbers or numeric strings and trace_id can be omitted for active trace.

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

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

The description clearly states the tool performs recursive child-slice expansion under given slice.id roots, aggregated per (depth, name) group. It distinguishes from siblings like chrome_main_thread_hotspots and execute_sql by specifying its use case: drilling into long tasks after those tools return a slice id.

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

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

Explicitly states when to use: after chrome_main_thread_hotspots or execute_sql returns a slice id, and that it avoids writing recursive CTEs. Does not explicitly list when not to use, but the context is clear given the required parameter and sibling tools.

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