Skip to main content
Glama
Sign In
ej-technologies

JProfiler

by ej-technologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

attach

Connect to a running JVM by PID or inside a Docker container to record CPU, JDBC, HTTP, and other performance data until you stop recording or capture allocation data.

Instructions

Attach to a running JVM by PID or to a JVM inside a Docker container. Records performance data for the following subsystems: cpu, jdbc, jpa, mongo_db, cassandra, http_server, http_client, ws, jndi, jms, kafka_consumer, rmi, grpc, ai, process until check_status is called with 'stopRecording: true', or allocation data when "recordingConfig": {"recordAllocations": true} is passed. Pass "recordingConfig": {"recordMonitors": true} to additionally record monitor and lock events. You can use list_jvms to discover JVMs.

Input Schema

NameRequiredDescriptionDefault
pidNoThe PID of a local JVM process, or the container PID (NSpid) of a JVM inside the specified container. If a container is specified and this is omitted, the topmost JVM in the container is used.
recordingConfigNoWhat to record in this session. Every key is optional and omitted keys keep their defaults - set only the keys this analysis needs, such as recordMonitors for lock contention analysis, recordAllocations for allocation sites, triggers for automatic captures during the recording, or advanced.methodCallRecordingType instrumentation when invocation counts are needed.
containerNameOrIdNoThe name or ID of a Docker container. When specified, profiling attaches to a JVM inside this container.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv16.3.0
  2. Removedv16.2.0
  3. Changed2 schema fields changedv16.1.9
    • removedInput schema / $defs
      Removed value: -{}
    • removedInput schema / definitions
      Removed value: -{}
  4. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose a valuable behavioral trait: this starts a persistent recording session that runs until explicitly stopped via check_status. But it says nothing about overhead, failure modes (target not attachable, JVM already attached, missing permissions), or what the call hands back, which the agent needs to proceed to check_status/attached_action.

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?

Front-loaded with the action and target, then the recording-scope sentence, then the discovery hint. The single long enumeration of subsystems is dense but earns its place by telling the agent what data will exist afterwards.

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 zero-required-param, deeply nested tool with no output schema, the description covers the essentials: target selection, what gets recorded, how recording terminates, and where to find PIDs. The main omission is that the agent is not told what a successful attach returns or whether follow-up calls need a session identifier.

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% and the nested recordingConfig is exhaustively documented inline, so the baseline is 3. The description's mentions of recordAllocations, recordMonitors and the default subsystem list restate what the schema already explains, adding little new meaning.

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?

States a specific verb and target: attach profiling to a *running* JVM, by PID or one inside a Docker container. The word 'running' implicitly separates it from prepare_profiling, and the recording scope (subsystem list, allocation vs performance) is spelled out, so the agent knows exactly what the call accomplishes.

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?

Gives an explicit discovery path ('use list_jvms to discover JVMs') and states how the recording ends (check_status with stopRecording, or an allocation-mode session). However, it never contrasts attach with prepare_profiling or states when not to attach (e.g. JVM already attached, JVM not yet started), which is the key sibling ambiguity here.

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