Skip to main content
Glama
Sign In
sleuths-mcp

sleuths-mcp

by threshbyte
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Analyze GC Log

analyze_gc_log

Parse JVM GC logs to summarize event counts, pause times, memory trends, and detect frequent Full GCs.

Instructions

Parse JVM GC logs and return: total GC events, Young/Full counts, average and max pause time, memory trend, and whether Full GC is frequent.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "logs": "<logs>"
    },
    "name": "analyze_gc_log"
  }
}

Input Schema

NameRequiredDescriptionDefault
logsYesGC log text (-Xlog:gc* output).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/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 usefully discloses what the analysis returns (event totals, Young/Full counts, pause stats, memory trend, frequent-Full-GC verdict), which is real behavioral value. It says nothing about input size/format limits, failure modes, or that it is a pure read operation.

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?

One front-loaded sentence with a clear verb and an enumerated result list; every phrase earns its place. Slightly dense but no waste.

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?

With no output schema, the description appropriately enumerates the returned metrics, which is exactly what an agent needs to judge relevance. The remaining gaps—input constraints and error behavior—are minor for a single-parameter read-only parser.

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 single `logs` parameter is fully documented there, so the baseline is 3. The description adds no additional meaning about the parameter beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (parse) plus resource (JVM GC logs) and enumerates the resulting metrics, which makes it clearly distinct from siblings like analyze_thread_dump or analyze_heap_histo. It stops short of naming those siblings explicitly.

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

Usage Guidelines2/5

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

No guidance on when to use this versus parse_exception_log or analyze_heap_histo, and no stated prerequisites (e.g., that the input must be -Xlog:gc* output, which is only in the schema). Usage is only inferable from the resource name.

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