diff --git a/evals/btrace-observability.json b/evals/btrace-observability.json index 87e8e44..644b8d6 100644 --- a/evals/btrace-observability.json +++ b/evals/btrace-observability.json @@ -141,12 +141,32 @@ "list_jvms", "pid", "duration", + "list_probes", "exit_probe" ], "mustAvoid": [ "grantAll=true" ], - "rubric": "Use the local MCP workflow: identify the PID, deploy a bounded latency probe, and explicitly remove it with exit_probe." + "rubric": "Use the local MCP workflow: identify the PID, check for probes left running with list_probes, deploy a bounded latency probe, and explicitly remove it with exit_probe." + }, + { + "id": "mcp-leftover-probe", + "prompt": "Yesterday an assistant session used the BTrace MCP server on my local JVM and I think it detached from a probe instead of stopping it. Is anything still running, and how do I get rid of it?", + "requiredSkills": [ + "btrace-observability", + "btrace-mcp-operations", + "btrace-probe-lifecycle" + ], + "mustMention": [ + "list_jvms", + "list_probes", + "pid", + "btrace -r" + ], + "mustAvoid": [ + "kill -9" + ], + "rubric": "Find the target PID, list detached probes with list_probes, explain that the MCP server cannot stop a probe it did not deploy in this session, and hand the operator the CLI reconnect command to stop it without killing the target JVM." }, { "id": "legacy-libs-migration", diff --git a/plugins/btrace-observability/mcp/README.md b/plugins/btrace-observability/mcp/README.md index bed24aa..33e6963 100644 --- a/plugins/btrace-observability/mcp/README.md +++ b/plugins/btrace-observability/mcp/README.md @@ -36,5 +36,3 @@ at its masked JAR: ```sh BTRACE_JAR=/path/to/btrace/btrace-dist/build/resources/main/v/libs/btrace.jar ./gradlew e2eTest ``` - -The `list_probes` case is disabled because the BTrace client exits the JVM after listing probes. diff --git a/plugins/btrace-observability/mcp/src/e2eTest/java/io/btrace/mcp/McpServerE2ETest.java b/plugins/btrace-observability/mcp/src/e2eTest/java/io/btrace/mcp/McpServerE2ETest.java index 8045d58..d22b307 100644 --- a/plugins/btrace-observability/mcp/src/e2eTest/java/io/btrace/mcp/McpServerE2ETest.java +++ b/plugins/btrace-observability/mcp/src/e2eTest/java/io/btrace/mcp/McpServerE2ETest.java @@ -22,7 +22,6 @@ import java.util.function.LongPredicate; import org.junit.jupiter.api.AfterAll; import org.junit.jupiter.api.BeforeAll; -import org.junit.jupiter.api.Disabled; import org.junit.jupiter.api.MethodOrderer; import org.junit.jupiter.api.Order; import org.junit.jupiter.api.Test; @@ -204,9 +203,6 @@ void exitProbeRemovesTheInstrumentation() throws Exception { @Test @Order(9) - @Disabled( - "BTrace Client.connectAndListProbes calls System.exit(0) after the reply, which terminates" - + " the MCP server process; needs a BTrace client change") void listProbesReportsTheRunningProbe() throws Exception { Map result = tool("list_probes"); assertSuccess(result); diff --git a/plugins/btrace-observability/skills/btrace-mcp-operations/SKILL.md b/plugins/btrace-observability/skills/btrace-mcp-operations/SKILL.md index 57ea461..f64edc8 100644 --- a/plugins/btrace-observability/skills/btrace-mcp-operations/SKILL.md +++ b/plugins/btrace-observability/skills/btrace-mcp-operations/SKILL.md @@ -6,13 +6,17 @@ description: Use when an AI client should operate BTrace through the BTrace MCP # MCP Operations The BTrace MCP server offers structured local-JVM operations such as `list_jvms`, `deploy_oneliner`, -`deploy_script`, `send_event`, `detach_probe`, and `exit_probe`. It is suitable when the AI client -and target JVM are on the same host and the operator wants an auditable conversational workflow. - -Do not call `list_probes`. The current BTrace client exits the process after returning the probe -list, which terminates the MCP server and drops every open probe session, so `send_event` and -`exit_probe` can no longer reach probes deployed earlier. Track each deployment yourself instead: -target PID, agent port, probe class or oneliner, and observation window. +`deploy_script`, `list_probes`, `send_event`, `detach_probe`, and `exit_probe`. It is suitable when +the AI client and target JVM are on the same host and the operator wants an auditable conversational +workflow. + +`list_probes` reports only probes that were detached with `detach_probe` and are still running on +the target; probes deployed in the current session that are still attached do not appear. Call it +before deploying, so probes left behind by an earlier session are found rather than stacked on, and +after any `detach_probe` to confirm what is still running. The MCP server cannot reconnect to or +stop a listed probe: report it to the operator, who can reconnect with `btrace -r ` +and stop it. Track your own deployments yourself: target PID, agent port, probe class or oneliner, +and observation window. Deployment results include only the probe's initial output; no tool returns what the probe prints afterwards. When the operator needs ongoing results, have the probe write them somewhere they can @@ -22,7 +26,8 @@ read, such as exported counters (`@Export` fields, read with `jcmd PerfCou boundaries. For those cases, first use `btrace-runtime-access` to place the client/server in the target environment. - Treat deployment and cleanup as one operation: record the target PID and call `exit_probe` after - the observation window. + the observation window. Prefer `exit_probe` over `detach_probe`; a detached probe keeps running + and is visible afterwards only through `list_probes`. - Use the server's `diagnose_slow_endpoint`, `find_exception_source`, and `profile_method` prompts as starting workflows, then apply the other plugin skills for scope and data safety. diff --git a/plugins/btrace-observability/skills/btrace-probe-lifecycle/SKILL.md b/plugins/btrace-observability/skills/btrace-probe-lifecycle/SKILL.md index 882f055..c331e03 100644 --- a/plugins/btrace-observability/skills/btrace-probe-lifecycle/SKILL.md +++ b/plugins/btrace-observability/skills/btrace-probe-lifecycle/SKILL.md @@ -12,8 +12,9 @@ condition. 2. Attach with an explicit output file when a durable incident record is required: `btrace -v -o trace.log Probe.java`. 3. Exercise the scenario or observe only for the agreed window. -4. Check active probes with `btrace -lp `; reconnect only when intentionally continuing an - existing probe with `btrace -r `. +4. List probes that a client detached from and that are still running with `btrace -lp ` (the + `list_probes` tool when working through the BTrace MCP server); reconnect only when + intentionally continuing an existing probe with `btrace -r `. 5. Stop/remove the probe at the end of the window, archive or delete the output according to policy, and remove temporary probe files from the target host/container/pod. diff --git a/plugins/perf-engineer/skills/perf-engineer/SKILL.md b/plugins/perf-engineer/skills/perf-engineer/SKILL.md index 8610e19..b2cc9bc 100644 --- a/plugins/perf-engineer/skills/perf-engineer/SKILL.md +++ b/plugins/perf-engineer/skills/perf-engineer/SKILL.md @@ -70,7 +70,8 @@ capability, record its actual command/tool identity in the session manifest. Confirm target identity, Java/runtime boundary, source repository and base commit, dirty-worktree state, available tools, recording window, output location, sensitivity policy, and profiling/live instrumentation approval. Check for existing async-profiler/JFR/BTrace sessions or conflicts before -attaching; ask before stopping or reconfiguring one. +attaching (for BTrace, the BTrace MCP server's `list_probes` tool or `btrace -lp ` lists +detached probes still running); ask before stopping or reconfiguring one. Create a session manifest and local supervisor. The supervisor owns child processes, leases, durable stop, timeout enforcement, cleanup, and state transitions. On restart, list active/orphaned sessions;