Skip to main content
Glama
Triggered0

lcu-mcp

by Triggered0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Correlate LCU WAMP and CDP console timelines

lol_forensics_correlate
Read-onlyIdempotent

Correlate LCU WAMP, Chrome DevTools Protocol logs, network requests, disk logs, and game telemetry into a unified timeline for incident triage. Identify if client state changes caused UI errors or network failures.

Instructions

Correlate events across LCU WAMP, Chrome DevTools Protocol console logs, network requests, disk logs, and live game telemetry into a unified chronological timeline. Use this tool during incident triage to identify whether client state changes triggered frontend UI errors or network failures. For a complete system report with status snapshots, use lol_forensics_bundle instead. For raw console logs alone, use lol_cdp_console_tail. Behavior: Safe and read-only. Gracefully combines active in-memory streams without interrupting background loggers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum total events to return across all streams (1-1000, default: 100)
sinceNoLower timestamp bound in epoch milliseconds or clock timestamp
untilNoUpper timestamp bound in epoch milliseconds or clock timestamp
formatNoOutput format: "narrative" (Markdown), "events" (JSON array), or "summary"narrative
levelsNoFilter CDP console log entries by severity levels: "error", "warning", "info", "log", "debug"
sourcesNoArray of telemetry stream sources to include: "wamp", "cdp", "network", "logs", "game"
logLevelNoFilter disk log entries by log level string
uriPrefixNoFilter WAMP events by URI prefix (e.g. "/lol-gameflow/")
networkFailedOnlyNoIf true, restricts CDP network requests strictly to transport/protocol failures

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.6.0
    • changedInput schema / properties / format / description
      Previous value: -"Output format"New value: +"Output format: \"narrative\" (Markdown), \"events\" (JSON array), or \"summary\""
    • changedInput schema / properties / levels / description
      Previous value: -"Filter CDP console entries by level"New value: +"Filter CDP console log entries by severity levels: \"error\", \"warning\", \"info\", \"log\", \"debug\""
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum total events to return"New value: +"Maximum total events to return across all streams (1-1000, default: 100)"
    • addedInput schema / properties / logLevel
      Added value: +{
+  "description": "Filter disk log entries by log level string",
+  "type": "string"
+}
    • addedInput schema / properties / networkFailedOnly
      Added value: +{
+  "description": "If true, restricts CDP network requests strictly to transport/protocol failures",
+  "type": "boolean"
+}
    • changedInput schema / properties / since / description
      Previous value: -"Lower timestamp bound in epoch ms or clock ts"New value: +"Lower timestamp bound in epoch milliseconds or clock timestamp"
    • addedInput schema / properties / sources
      Added value: +{
+  "description": "Array of telemetry stream sources to include: \"wamp\", \"cdp\", \"network\", \"logs\", \"game\"",
+  "items": {
+    "enum": [
+      "wamp",
+      "cdp",
+      "network",
+      "logs",
+      "game"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / until / description
      Previous value: -"Upper timestamp bound in epoch ms or clock ts"New value: +"Upper timestamp bound in epoch milliseconds or clock timestamp"
    • changedInput schema / properties / uriPrefix / description
      Previous value: -"Filter WAMP events by URI prefix (e.g. /lol-gameflow/)"New value: +"Filter WAMP events by URI prefix (e.g. \"/lol-gameflow/\")"
  2. Addedv0.2.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description nonetheless adds non-obvious operational context: it combines active in-memory streams 'without interrupting background loggers,' which reassures the agent it won't perturb live capture. It stops short of describing result size limits or how streams are interleaved on timestamp ties.

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?

Four sentences, no filler: capability first, use case second, sibling routing third, behavioral guarantee last. Every sentence earns its place and the most important routing information is front-loaded before the alternatives.

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 9-parameter aggregation tool with no output schema, the description covers what it merges, when to use it, and its safety/interruption profile. The one gap is that it doesn't indicate the volume or shape of results (e.g., bounded by limit, possibly narrative Markdown), leaving the agent to infer output characteristics from the format parameter alone.

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% across all 9 parameters, so the schema already documents limit, since/until, format, levels, sources, logLevel, uriPrefix, and networkFailedOnly. The description's list of telemetry streams loosely maps to the `sources` enum, which is marginally helpful, but it adds no filter syntax or format-selection guidance beyond the schema. Baseline 3 applies.

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 ('Correlate') and enumerates the exact resources merged (LCU WAMP, CDP console logs, network requests, disk logs, live game telemetry) with the output shape (unified chronological timeline). An agent can distinguish this from every sibling without opening a schema.

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?

Explicitly frames the use case ('during incident triage to identify whether client state changes triggered frontend UI errors or network failures') and routes to two named alternatives with their selecting conditions: lol_forensics_bundle for a full report and lol_cdp_console_tail for raw console logs alone.

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