Skip to main content
Glama
walac

perf-mcp

by walac

perf_script

Dump raw per-sample events from perf.data with configurable fields for flamegraph input, custom filtering, or inspecting individual events.

Instructions

Dump raw per-sample events from perf.data. Each line is one sample with configurable fields.

Use this when you need the raw data rather than aggregated histograms — for flamegraph input, custom filtering, or inspecting individual events.

Key parameters:

  • fields: comma-separated output fields. Common sets: 'comm,pid,tid,time,event,ip,sym,dso' (general), 'ip,sym,dso' (flamegraph input), 'comm,tid,time,ip,sym,srcline' (source mapping). Available: comm,tid,pid,time,cpu,event,trace,ip,sym,dso,addr,symoff,srcline,period,flags,callindent,insn,brstacksym.

  • symbols/dsos/comms/pid/tid: filter to specific functions/DSOs/processes.

  • time: restrict to time range 'start,stop'.

  • max_events: limit number of events returned.

  • header_only: show file metadata only.

  • show_task_events/show_mmap_events/show_switch_events: include non-sample events.

  • call_trace/call_ret_trace/insn_trace: Intel PT trace modes.

Output: one line per sample. Format depends on fields parameter. Works on any perf.data from perf record.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nsNoShow times in nanoseconds
cpuNoList of CPUs to filter
pidNoOnly consider symbols in these PIDs
tidNoOnly consider symbols in these TIDs
xedNoUse Intel XED disassembler
dsosNoOnly consider these DSOs
timeNoTime span of interest (start,stop)
commsNoOnly display events for these comms
forceNoDon't complain, do it
inputYesPath to perf.data file
symfsNoSymbol filesystem root
fieldsNoComma-separated list of fields to display: comm,tid,pid,time,cpu,event,trace,ip,sym,dso,addr,symoff,srcline,period,iregs,uregs,brstack,brstacksym,flags,bpf-output,brstackinsn,brstackoff,callindent,insn,insnlen,synth,phys_addr,metric,misc,ipc,tod,data_page_size,code_page_size,ins_lat,machine_pid,vcpu,cgroup,retire_lat,brstackinsnlen,parallelism,latency
headerNoShow data header
inlineNoShow inline function
itraceNoInstruction Tracing options
LatencyNoShow latency attributes
reltimeNoShow relative time
stop_btNoStop unwinding callchain at this symbol
symbolsNoOnly consider these symbols
verboseNoVerbosity level (0-2)
vmlinuxNovmlinux pathname
all_cpusNoSystem-wide collection from all CPUs
demangleNoSymbol demangling (default on)
kallsymsNokallsyms pathname
deltatimeNoShow delta time
max_stackNoMaximum stack depth for callchains
show_infoNoDisplay extended perf.data info
addr_rangeNoFilter by address range
call_traceNoShow call trace
guest_codeNoDisplay guest code
guestmountNoGuest OS root file system mount point
insn_traceNoShow instruction trace
max_blocksNoMaximum number of code blocks to dump
max_eventsNoMaximum number of events to display
stitch_lbrNoEnable LBR callgraph stitching
header_onlyNoShow only data header
guestmodulesNoGuest modules file
guestvmlinuxNoGuest vmlinux pathname
guestkallsymsNoGuest kallsyms file
call_ret_traceNoShow call/return trace
dump_raw_traceNoDump raw trace in ASCII
graph_functionNoShow callgraph for specific function(s)
per_event_dumpNoDisplay record as parsed event
demangle_kernelNoEnable kernel symbol demangling
hide_call_graphNoDon't display the callchain
show_bpf_eventsNoDisplay BPF events
full_source_pathNoShow full source file name path
merge_callchainsNoMerge deferred callchains
show_kernel_pathNoShow kernel DSO path instead of [kernel.kallsyms]
show_lost_eventsNoDisplay lost events
show_mmap_eventsNoDisplay mmap-related events
show_task_eventsNoDisplay task-related events (fork/comm/exit)
show_round_eventsNoDisplay finished round events
show_cgroup_eventsNoDisplay cgroup events
show_switch_eventsNoDisplay context switch events
show_namespace_eventsNoDisplay namespace events
show_text_poke_eventsNoDisplay text poke events

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description fully discloses behavior: one line per sample, configurable fields, works on any perf.data from perf record, and special trace modes. It also mentions output format and key filtering options, giving the agent a clear picture of side effects (none destructive).

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?

The description is structured with a clear opening, use-case paragraph, and key-parameter list; every sentence adds operational value. It is longer than the calibration high example but justified by the tool's complexity (57 parameters), and it remains scannable.

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?

For a 57-parameter tool, the description covers the core behavior, output format, and the most impactful parameter groups. Since an output schema exists, the description doesn't need to explain return values, and it provides enough context for correct invocation alongside the fully documented schema.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds substantial value by listing common field sets for 'fields' and summarizing filter parameters (symbols, dsos, comms, pid/tid, time, max_events) beyond their schema definitions. This helps the agent choose parameter values.

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 starts with a specific verb ('Dump raw per-sample events from perf.data') and clearly distinguishes from aggregated histogram tools like perf_report by emphasizing raw per-sample output. The use cases (flamegraph input, custom filtering, inspecting individual events) further differentiate it from siblings.

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?

It explicitly states when to use: 'when you need the raw data rather than aggregated histograms' and names concrete scenarios. It doesn't name sibling tools directly but clearly contrasts with the histogram-based alternative, which is sufficient for tool selection.

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/walac/perf-mcp'

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