Skip to main content
Glama
Triggered0

lcu-mcp

by Triggered0

Start tailing the client console

lol_cdp_console_start

Begin tailing the League client renderer console, buffering logs and uncaught exceptions. Call before the event; logs survive page reloads and reattach on UI restart.

Instructions

Attach to the client renderer and begin buffering console output and uncaught exceptions in the background. A page reload does not interrupt this: the debug target survives it, so logging continues with no gap and no reattach entry. Only when the target itself is destroyed and recreated — the client UI restarting — does the tailer re-attach, and it records a "reattach" entry for that. Call this BEFORE the thing you want to capture: the buffer only holds what arrived after it started.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that the target survives a page reload so logging continues without a gap, and that only a target destruction/recreation triggers a re-attach plus a recorded 'reattach' entry. It omits auth/permission requirements and buffer size or retention limits.

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?

Three tight sentences, each carrying distinct information (what it does, reload survival, ordering constraint). The action and the key 'call before' constraint are front-loaded with no filler.

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 no-param, no-output-schema lifecycle tool, the description covers initiation behavior, persistence semantics, and timing thoroughly. It could be marginally more complete by pointing to lol_cdp_console_tail for reading the buffer it fills.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly describes the operation as a no-argument background attach and adds no misleading parameter implications.

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+resource: attaching to the client renderer and buffering console output plus uncaught exceptions. It is clearly distinguishable from the sibling lol_cdp_console_tail (which reads the buffer) and lol_cdp_console_stop (which ends it).

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 ordering rule: 'Call this BEFORE the thing you want to capture,' because the buffer only holds what arrived after start. It does not explicitly name the read/stop siblings as the natural next steps, so it stops short of full when/when-not routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.