Skip to main content
Glama

query

Evaluate jq expressions against JProfiler performance or heap datasets to filter, sort, aggregate, and drill into profiling results.

Instructions

Query a performance or heap dataset with a jq expression and return the result. The dataset is materialized lazily and cached per session. Each query is independent, there is no current object: builtins take explicit ids bound from earlier results, e.g. .instances[0].id as $id | {value: preview($id), keptAliveBy: pathToRoot($id).paths[0].path | map(.class)}

Input Schema

NameRequiredDescriptionDefault
idNoThe expansionId of a row from a previous hotspots, callTree, allocation, probe.events, probe.controlObjects or threads.dumps query for the expand dataset, or the id of a biggest object from heap.biggestObjects for the retained dataset
opNoThe filter operation for field: string comparisons (contains, startsWith, endsWith, equals, regexp), object fields (null, nonNull), numeric equals or a from/to range
toNoInclusive upper bound for a numeric range filter or the end of the time window in seconds since recording start (telemetry.series, monitor.*)
setNoOptional for heap.instances, heap.sizes and heap.inspectionResult: a set value from a previous heap result, the operation runs on that object set instead of a class or the whole heap; class, packageFilter and the value filter cannot be combined, filterScript and generation still apply
argsNoArguments for parametric datasets, see the jprofiler://datasets resource or the datasets list in check_status
fromNoInclusive lower bound for a numeric range filter or the start of the time window in seconds since recording start (telemetry.series, monitor.*)
lineNoOptional for telemetry.series: restrict the series to one line by name
nameNoOptional for mbean.snapshots: an MBean object name, requires the snapshot argument
sortNoOptional for probe.events: the global selection and output order - 'duration' (default) keeps and returns the slowest events, 'startTime' the most recent ones
textNoOptional for probe.events and probe.controlObjects: text filter matched against the event description and all text payloads or the object name and text properties, comma-separated alternatives, matching per matchMode
classNoRequired for heap.instances: the class to list instances of, a name value from heap.classes (after the first query, omitting it continues with the last used class)
fieldNoOptional value filter on heap.instances: a field path like customer.name or orders[].id
limitNoOptional row limit for heap.instances, javascript.origins, monitor.history and threads.list, the defaults and caps are documented per dataset in the check_status catalog
scopeNoOptional for javascript.origins: 'recorded' (default) lists only the origins whose requests reached the profiled application, 'all' every origin the browser extension reported, with a recorded flag per row
stateNoOptional for probe.controlObjects: 'open' (default) lists only objects still open, 'closed' only closed objects, 'all' both, 'collectedWithoutClose' (only jdbc with leak recording) connections that were garbage collected without close
typesNoOptional for probe.events: event type names to include, comma-separated or as a JSON array, e.g. the type values of previous rows (open/close names or probe-specific names like 'Statement execution')
valueNoThe comparison value for field and op
columnNoOptional for probe.eventHistogram: the measured value, 'duration' (default), 'throughput' for file/socket probes, or a numeric payload property name from probe.events rows
metricNoOptional for performance datasets of probe subsystems that record a size or token measurement (file, socket, AI): the measurement the hotspots and call tree are ranked by. 'duration' (default) measures event durations, the alternatives are listed in the probeMetrics section of check_status (e.g. write_throughput). Value properties in the result are then named by the metric unit (bytes, tokens) instead of micros. Cannot be combined with threadStatus
threadNoOptional for performance datasets: restrict the analysis to selected threads. 'all' (default) merges all threads, 'virtual' merges all virtual threads into one, an integer thread id selects a single thread - use a threadId from threads.list rows (the same ids the monitor datasets use). Cannot be combined with threadGroup
datasetYesThe dataset to query. The jprofiler://datasets resource documents all datasets with arguments, row formats and examples, check_status lists them with availability for the current session
groupByNoOptional for monitor.stats: the aggregation grouping, default monitors
minCountNoOptional for performance.outliers: only methods with at least this many invocations, default 10
snapshotNoOptional for mbean.snapshots: the index of an MBean snapshot from the catalog
threadIdNoOptional for monitor.history and monitor.graph: restrict to one waiting or owning thread id from monitor.stats
eventTypeNoOptional for monitor.history: restrict to one event type
matchModeNoOptional for probe.events and probe.controlObjects: how text is matched, default contains
maxEventsNoOptional for probe.events: page size of the global top-N selection, default 1000, max 10000
maxMicrosNoOptional for probe.events: maximum event duration in microseconds
maxPointsNoOptional for telemetry.series and monitor.timeline: number of consolidated points per line, default 120, max 500
minMicrosNoOptional for probe.events: minimum event duration in microseconds
monitorIdNoOptional for monitor.history and monitor.graph: restrict to one monitor id from monitor.stats
subsystemNoThe subsystem to analyze, a value from availableSubsystems in check_status (e.g. cpu, jdbc). If the session recorded a single subsystem it is used automatically
telemetryNoRequired for telemetry.series: the telemetry to fetch, an id from telemetry.list (e.g. heap, cpu, threads, heap/PS Eden Space, gc/G1 Young Generation, custom/<name>, jdbc/<group>)
expressionYesThe jq expression, passed as a plain JSON string without surrounding quotes. . returns the dataset unchanged. Datasets are objects, the rows are in the hotspots, callTree, classes or biggestObjects array. Filtering, sorting, projection and aggregation belong in the expression. Examples: .hotspots | sort_by(-.percent) | .[0:10], .hotspots | map({method, percent, expansionId}) | .[0:5] (keep expansionId for drill-downs) or .hotspots | group_by(.method | split(".")[0]) | map({pkg: .[0].method, hotspots: length}) (delivered rows only, exact rollups of the complete recording come from the aggregation parameter). Project tree rows one level at a time: .callTree | map({method, micros, children: [(.children // [])[] | .method]}) - children and callers are omitted on leaves and omitted arrays cannot be iterated, and multi-step values in an object construction must be wrapped in parens: {key: (expr | filter)}. Drill down with the builtin expand(expansionId) inline: .hotspots | sort_by(-.percent) | .[0] | {method, callers: expand(.expansionId).callers}. Retained classes of a biggest object with the builtin retained(id): .biggestObjects | sort_by(-.retainedSize) | .[0] | {class, retained: retained(.id).classes}. Combined size analysis of an object set with the builtin sizes([ids]): .biggestObjects | {top: .[0:3] | map(.class), sizes: sizes([.[0:3][].id])}. References of a heap object with the builtins incoming(id)/outgoing(id): .instances[0] | {name, heldBy: incoming(.id).referrers | map(.class)}. GC root paths with pathToRoot(id) and value previews with preview(id): .instances[0] | {name, value: preview(.id), keptAliveBy: pathToRoot(.id).paths[0].path | map(.class)}. Capture the input before binding variables: . as $rows | ((map(.micros) | add) as $t | ...), wrap generators in constructions with [...]. Keep results small: project fields and slice with .[0:N].
filterPathNoOptional with filterScript: a field path like customer.name or orders[].id, the script is evaluated on the objects the path navigates to instead of the instances of the class
generationNoOptional on heap.classes, heap.biggestObjects and heap.instances: restrict to objects allocated after (new) or before (old) the last markHeap action of the recorded session
ignoreCaseNoIgnore case for string comparisons, default false
inspectionNoRequired for heap.inspectionResult: the inspection to run, an id from heap.inspections
limitBytesNoOptional byte budget for the result, default 24000. Larger results are truncated and marked as such
maxBucketsNoOptional for probe.eventHistogram: maximum bucket count, default 100, max 1000 - the histogram adapts its bucket size to stay below
maxObjectsNoOptional for probe.controlObjects: maximum number of objects per state, default 200, max 2000
aggregationNoOptional for performance and allocation datasets: the rollup level of the tree nodes. 'method' (default) aggregates per method, 'class' per class, 'package' per package, 'component' by Spring, JEE and JPA component class (controllers, services, repositories, empty for apps without such components). Class, package and component rollups are exact, they include everything below the row cutoffs of the method view, and they shrink huge deep trees to an overview. Drill back in with 'method' and a packageFilter
groupScriptNoRequired for the custom_grouping inspection: a Java script evaluated per object that returns the group key string, null skips the object. Read the jprofiler://api/heap-scripts resource for the script API before writing a script
threadGroupNoOptional for performance datasets: restrict the analysis to one thread group, a group value from threads.list rows (platform threads only, virtual threads have no groups). Cannot be combined with thread
filterScriptNoOptional for heap.instances and heap.sizes: a Java script evaluated per object, keeping objects where it returns true - for predicates the value filter cannot express. Read the jprofiler://api/heap-scripts resource for the script API before writing a script
minMaxMicrosNoOptional for performance.outliers: only methods whose slowest invocation took at least this many microseconds, default 10000
threadStatusNoOptional for performance datasets: the thread state whose time is counted. 'running' (default for cpu) counts only time while the thread is scheduled by the OS, waiting on sockets, locks or other threads is not included. 'all' (default for probes) counts wall clock time in all states. 'net_io' counts time waiting on network or file I/O, the state of slow database or REST calls. 'waiting' and 'blocked' count time waiting on other threads or blocked on a monitor, for inter-thread handoff and lock contention analysis. Only 'all' and 'running' carry invocation counts for cpu. Not available for JFR probe subsystems
packageFilterNoOptional package filter to focus on classes of interest (heap datasets and performance subsystems), comma-separated or as a JSON array
payloadFilterNoOptional filter on payload descriptions (SQL statements, URLs) for probe subsystems, applied to hotspots and call trees before the row cutoffs. Each pattern keeps descriptions that contain it, case-sensitive, * and ? are literal characters (a lone * means no filter), comma-separated or as a JSON array, a pattern with a comma needs the array form
controlObjectIdNoOptional for probe.events: restrict to the events of one control object, a controlObjectId from probe.controlObjects or probe.events rows
minDurationMicrosNoOptional for monitor.history: minimum event duration in microseconds

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv16.3.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It usefully discloses that datasets are materialized lazily and cached per session, and that queries are independent rather than operating on a mutable current object. It does not explicitly state that the operation is read-only, whether it can cause side effects, how errors are surfaced, or any permission or rate-limit considerations.

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 front-loaded with the core purpose, followed by concise behavioral context and a compact jq example. The example earns its place by showing the explicit-id binding pattern required for builtins. The only inefficiency is the overly narrow 'performance or heap dataset' phrasing in the opening sentence.

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?

For a complex 52-parameter tool with no output schema, the schema itself provides very rich parameter documentation and points to external dataset resources. The description supplies the critical jq-expression model and builtin usage pattern that an agent needs in order to construct queries correctly. It is still somewhat thin on result behavior and dataset availability, but the structured schema compensates for much of that.

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 baseline is 3 even without additional parameter explanations. The description reinforces the expression parameter with builtin examples and the 'no current object' model, but most dataset and argument semantics are already covered in the schema. It adds limited meaning beyond the structured parameter documentation.

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

Purpose4/5

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

The description gives a clear verb-resource pairing: query a dataset using a jq expression and return the result. It distinguishes the tool from lifecycle-oriented siblings such as prepare_profiling and check_status. However, it says 'performance or heap dataset' even though the schema supports telemetry, monitor, probe, threads, GC, and other datasets, so the stated scope is narrower than the actual tool.

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

Usage Guidelines3/5

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

The description explains that each query is independent and that there is no 'current object', which is useful operating guidance. It also demonstrates how to bind ids from earlier results for builtins. It does not explicitly say when to use this tool versus check_status, load_snapshot, or ad-hoc query alternatives, nor does it state any exclusions beyond the no-current-object model.

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