Skip to main content
Glama
software-mansion

Argent

Official
by software-mansion
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

react-profiler-start

Start CPU profiling and React commit capture on Hermes runtime. Handles existing sessions gracefully and offers force option to take over.

Instructions

Start CPU profiling + React commit capture on the connected Hermes runtime. Delegates React commit capture to the in-app React DevTools backend (ri.startProfiling). If another tool-server already owns the session, returns { already_running: true, owner, stale, how_to_reclaim } without clobbering their data. Pass { force: true } to reclaim a fresh owner's session, but BEFORE OVERTAKING - ask the user for approval first, see relevant skill for guidance. Before calling this, ask the user if they also want native profiling (native-profiler-start) — recommend running both in parallel for a complete picture. After starting, ask the user to perform the interaction to profile, then call react-profiler-stop. Returns { started_at, startedAtEpochMs, hermes_version, detected_architecture } on success, or the already_running payload described above. Fails if the Hermes runtime is not reachable or the Metro CDP connection cannot be established.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
portNoMetro server port. Optional — omit it to use this device's port, 8081 by default. Ignored for Chromium, whose CDP port is encoded in device_id.
forceNoTake over an active profiling session even when it is owned by another tool-server and still fresh. Set to true only when you know the prior owner is gone.
device_idYesDevice id from list-devices — the SAME id you passed to debugger-connect (iOS simulator UDID or Android serial).
sample_interval_usNoCPU sampling interval in microseconds (default 100)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.25.0
    • removedInput schema / properties / port / default
      Removed value: -8081
    • changedInput schema / properties / port / description
      Previous value: -"Metro server port"New value: +"Metro server port. Optional — omit it to use this device's port, 8081 by default. Ignored for Chromium, whose CDP port is encoded in device_id."
    • addedInput schema / properties / port / maximum
      Added value: +65535
    • addedInput schema / properties / port / minimum
      Added value: +1
    • changedInput schema / properties / port / type
      Previous value: -"number"New value: +"integer"
  2. Changed1 schema field changedv0.17.0
    • changedInput schema / properties / device_id / description
      Previous value: -"Device logicalDeviceId from debugger-connect (iOS simulator UDID or Android logicalDeviceId)."New value: +"Device id from list-devices — the SAME id you passed to debugger-connect (iOS simulator UDID or Android serial)."
  3. First observedv0.15.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the ownership-handling behavior (already_running payload), failure conditions (Hermes unreachable, Metro CDP connection failure), and the delegation to in-app backend. It also warns about clobbering data and specifies the return payloads on success vs. already-running scenarios.

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 long but deliberately structured: it opens with the core action, then covers ownership semantics, the interactive workflow, return payloads, and failure modes in a logical order. Each sentence adds necessary information without redundancy. The front-loading of purpose and the step-by-step guidance make it highly scannable for an agent.

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 tool with a multi-step workflow, ownership conflicts, and failure conditions, the description covers everything an agent needs to invoke it correctly: prerequisites (connected Hermes runtime, debugger-connect), the interactive sequence (ask user → start → user interaction → stop), edge cases (already_running, force), and environmental constraints (Metro CDP connection). No gaps are evident.

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 the schema already documents all four parameters. However, the description adds meaningful context beyond the schema: it clarifies that port is optional and ignored for Chromium (encoding CDP port into device_id), explains when to set force to true (and the approval requirement), and references how device_id should be the same as passed to debugger-connect. This goes beyond simple parameter names.

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 ('Start CPU profiling + React commit capture on the connected Hermes runtime'), and clearly distinguishes itself from siblings like native-profiler-start and react-profiler-stop. It also explains the delegation to the in-app React DevTools backend, making its role unambiguous.

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?

The description gives explicit when-to-use guidance: it tells the agent to ask the user about native profiling before calling, recommends running both profilers in parallel, and instructs to call react-profiler-stop after the user performs the interaction. It also covers the force parameter with a mandatory approval step and clarifies when not to use force (when prior owner is still active).

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

Deploy Server

Other Tools