Skip to main content
Glama

tv_heap

Take a device heap snapshot and compare two snapshots to detect leaks: see total nodes, shallow size, detached DOM nodes, and top constructors' growth/shrink.

Instructions

Take a heap snapshot on the device and/or compare two of them — the tool for "the heap grew and never came back". Leak hunt: tv_heap action:"snapshot" (before) -> do the scenario (tv_press / tv_menu / tv_sequence) -> tv_heap action:"snapshot" (after) -> tv_heap action:"diff" with the two paths. A snapshot writes a .heapsnapshot file (open it in Chrome DevTools -> Memory -> Load) and returns the Summary view in numbers: total nodes and shallow size, how many DETACHED DOM nodes are still retained, and the top-N constructors by shallow size. diff returns the deltas — which constructors gained objects and bytes (topGrowth) and which lost them (topShrink), like the DevTools Comparison view. Retainer paths ("who holds this") and retained/dominator sizes are deliberately NOT computed: load the saved files in DevTools for those. A snapshot forces a full GC and pauses V8 for a long time (it can take a minute on a TV), so it is refused while a tv_profile recording is running. Needs the HeapProfiler domain — fine on tizen55/webos7/pc, best-effort on webOS 3. diff is a pure file operation: no device needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNosnapshot: where to write the .heapsnapshot. Defaults to a scratch path.
topNNoHow many constructors to report (default 20).
afterNodiff: path to the later .heapsnapshot.
actionYessnapshot: take one on the device. diff: compare two files already on disk.
beforeNodiff: path to the earlier .heapsnapshot.
deviceNoDevice id from devices.json. Omit to use the default device.
timeoutMsNosnapshot: give up after this long (default 120000 — a full heap off a slow TV legitimately takes tens of seconds).
Behavior5/5

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

No annotations exist, so the description carries the full burden. It discloses side effects (full GC, long V8 pause, can take a minute on TV), refusal while a profile runs, platform compatibility (tizen55/webos7/pc, best-effort on webOS 3), and what is deliberately NOT computed (retainer paths, retained/dominator sizes). This is exemplary transparency.

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 longer than typical but every sentence carries valuable information: purpose, workflow, output, limitations, platform support, and operational constraints. It is front-loaded with the main purpose and then logically structured. It could be slightly tighter, but the density is justified for a complex tool.

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?

Despite having no output schema, the description explains exactly what the return values are (Summary view numbers, diff deltas with topGrowth/topShrink). It covers prerequisites (HeapProfiler domain), edge cases (diff is pure file operation with no device needed), and performance caveats. This is complete enough for an agent to decide when and how to invoke it.

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 workflow context (snapshot before/after, diff with two paths), clarifies the output of each action, and disambiguates the 'path' default ('Defaults to a scratch path') and 'topN' semantics. It enriches the schema's bare descriptions with meaningful usage context.

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 opens with a specific verb and resource: 'Take a heap snapshot on the device and/or compare two of them'. It clearly distinguishes from sibling tools (e.g., tv_profile, tv_console) by focusing on heap analysis. It also explains the two actions (snapshot/diff) and their outputs.

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?

Provides an explicit leak-hunting workflow with before/after steps, names sibling tools (tv_press/tv_menu/tv_sequence) as part of the scenario, and explicitly states when NOT to use it (refused during tv_profile recording). It also directs users to DevTools for retainer paths, covering alternatives.

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/Ediand11/tv-debug-mcp'

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