trace_status

[debug]

Returns GliderTrace readiness, workspace and artifact configuration, package expiration, retention/redaction defaults, telemetry state, this server process’s own resource use, which build/test/restore runners are usable on this machine, and optional local diagnostic capability details.

Why this tool exists

Runtime evidence workflows need a quick way to confirm workspace, artifact, retention, and diagnostics capability before collecting data.

How it helps the agent

The model can verify that GliderTrace is ready and see local capability limits before starting expensive or sensitive capture work.

Try it locally in the GliderTrace playground

Parameters

NameTypeRequiredDescription
includeEnvironmentbooleanNoInclude OS/runtime details, local diagnostic tool discovery, and resolution of the enabled <code>--allow-executable</code> policies (Visual Studio MSBuild, workspace NuGet.exe, vstest.console.exe) so runner availability is answered rather than reported as unprobed.

Examples

Check GliderTrace readiness

Request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "trace_status",
    "arguments": {}
  }
}

Check which build/test/restore runners work here before the first run

Request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "trace_status",
    "arguments": {
      "includeEnvironment": true
    }
  }
}

Check whether this server process is leaking handles or memory

Request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "trace_status",
    "arguments": {}
  }
}

Response Notes

Returns server version, workspace root, artifact root, retention/redaction defaults, a <code>telemetry</code> block (<code>enabled</code> plus the reason it is off), and a <code>capabilities</code> block listing each executable policy and the runners for <code>trace_run_tests</code>, <code>trace_build</code>, and <code>trace_restore</code> with a reason when one is unavailable. A <code>process</code> block reports this server process’s own <code>handles</code>, <code>privateMemoryMb</code>, <code>threads</code>, <code>uptimeMinutes</code> and <code>sampledUtc</code>, plus <code>diagnosticsLog</code> — the directory holding a capped local NDJSON history of those readings, written every five minutes and never sent anywhere. The block is absent until the first sample is taken, and on a platform that does not report a handle count. Executable resolution and local diagnostic tool discovery are included only when <code>includeEnvironment</code> is true.

↑/↓ NavigateEnter OpenSpace Expand