Skip to main content
Glama

native-profiler-start

Begin native CPU, hang, and memory profiling on a booted iOS or Android device. Automatically detects the running app process. Returns recording status and trace file.

Instructions

Start native profiling on a booted device. iOS: Instruments via xctrace (CPU, hangs, memory). Android: Perfetto (CPU, jank, RSS-growth weak signal). Auto-detects the running app process unless app_process is explicitly provided. After starting, let the user interact with the app, then call native-profiler-stop. Use when you want to capture native CPU, hang, and memory data for a running app. Returns { status, pid, traceFile } confirming the recording has started. Fails if no app is running on the device, or the profiler cannot attach to the process.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
device_idYesTarget device id from `list-devices` (iOS UDID or Android serial).
app_processNoiOS: the CFBundleExecutable or display name of the app to profile. Android: the app's package name. If omitted, auto-detects the currently running foreground app. Only provide this if auto-detection picks the wrong app.
template_pathNoiOS-only: path to an Instruments .tracetemplate file (defaults to bundled Argent template). Ignored on Android.
malloc_stack_loggingNoiOS-only. When true, cold-launches the app under the profiler with Malloc Stack Logging enabled so memory leaks carry an allocation backtrace (responsible frame + library). Without it, leaks are still detected but unattributable — Instruments reports '<Call stack limit reached>'. Trade-offs: this RESTARTS the app (current state is lost), adds memory/CPU overhead, and makes the app noticeably slow to launch (every startup allocation records a backtrace), so leave it off for pure CPU/hang profiling. Requires a non-degraded Xcode: on Xcode 26.4 and later the cold-launch path is broken, so the call is rejected up front (re-run without the flag, or set ARGENT_IOS_CAPTURE=device to override if the device path works on your host). ARGENT_IOS_CAPTURE=all-processes — e.g. exported globally for the normal capture path — also rejects this flag up front, since that fallback cannot cold-launch; unset it (or set it to device) first. Ignored on Android.
Behavior5/5

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

With no annotations, description fully covers traits: auto-detection of app process, fail conditions, workflow steps, and detailed trade-offs for malloc_stack_logging (cold launch, overhead, Xcode restrictions). 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?

Well-structured with clear paragraphs for each platform. Every sentence adds value, but the long paragraph for malloc_stack_logging could be slightly trimmed. Front-loaded with core purpose.

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 complex tool with 4 parameters and no output schema, the description covers purpose, usage, behavior, failure conditions, and return value shape ({ status, pid, traceFile }). All essential aspects are addressed.

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 coverage is 100% with highly detailed descriptions for each parameter. The main description adds minimal extra param context beyond summarizing auto-detection, which is already in schema. Baseline 3 is correct.

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 clearly states the tool starts native profiling on a booted device, specifies iOS/Android methods (Instruments/Perfetto), and captures CPU, hangs, memory. It distinguishes itself from siblings like native-profiler-stop and native-profiler-analyze.

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

Usage Guidelines4/5

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

Explicitly states when to use: 'Use when you want to capture native CPU, hang, and memory data for a running app.' Provides workflow instruction to call native-profiler-stop after user interaction. However, no direct comparison to sibling profiler tools (e.g., react-profiler-start) is given.

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/software-mansion/argent'

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