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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full behavioral burden. It usefully discloses a real side effect — buffered entries are discarded — which is exactly the kind of irreversibility hint an agent needs. It stops short of saying what happens when no tailer is running, whether the call is idempotent, or whether it errors, so coverage is partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with zero filler. The primary action comes first and the consequence follows immediately, so nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter teardown tool with no output schema and no annotations, the description covers the action and the main side effect. A note on the precondition (an active tailer) or error behavior would close the remaining gap, but an agent can call this correctly as written.

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

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

The schema is an empty object with zero parameters and full coverage, so there is nothing for the description to document. Baseline 4 applies.

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

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

The description states a concrete verb and resource ('Detach and close the tailer socket'), which maps cleanly to the tool name and title. It does not, however, explicitly distinguish itself from siblings like lol_cdp_console_start, lol_cdp_console_tail, or lol_events_stop, so an agent must infer that this is the teardown counterpart.

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

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

Usage is only implied: the name and the paired start/tail siblings make it clear this ends a console tailing session, but the description never states when to call it, what precondition it expects (an active tailer), or when an alternative teardown tool is preferable. Adequate but with clear gaps.

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

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

With no annotations, the description carries the full load and does well: it explains the ts vs pageTs clocks and their difference as a latency signal, discloses that 'reattach' entries bypass every filter because reloads are context, and states that a stopped tailer produces an error rather than an empty result. It stops short of stating read-only/repeat-safety or the cost of large limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no filler: purpose first, then the timestamp model, then filter-exemption and failure semantics. The latency-signal framing is dense but front-loaded and each sentence carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, zero-required, annotation-free read tool with no output schema, the description covers timestamp fields, filter-exempt entries, and error behavior, but never describes the shape of a returned entry (message, level, seq) or how cursor and limit interact for pagination. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters and the baseline is 3. The description reinforces cursor semantics and explains that ts bounds (the 'since'/'until' params) are epoch milliseconds on the process's anchored clock, but adds no syntax or format detail the schema lacks.

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

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

States a specific verb and resource ('Return buffered console entries') and adds the incremental-read mechanism ('after your cursor'), which inherently separates it from the sibling start/stop console tools. An agent knows this is a cursor-based polling read, not a one-shot dump or a lifecycle control.

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

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

The phrase 'after your cursor' implies the intended incremental-polling pattern, and the error behavior hints at a prerequisite (tailer must be running). However, no alternatives are named (e.g. lol_cdp_console_start, lol_events_poll) and there is no explicit when-not guidance, so usage must be inferred.

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

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

No annotations are provided, so the description carries the full burden. It does add useful behavioral context: returns both an MCP image content block AND JSON metadata, and optionally saves to disk. However, it doesn't disclose failure modes (e.g., what happens if CDP isn't connected, whether targetId defaults to active page is described in the schema not description), or whether this is read-only. Moderate disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single well-structured sentence with the key mechanism and outputs front-loaded. No waste, though it could be tightened slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should carry more weight. It notes the return shape (image block + JSON metadata) which is helpful, but lacks prerequisites (CDP must be active), failure behavior, and any note that this is a read/safe operation. Adequate but with clear gaps.

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

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

Schema coverage is 100%, so all four parameters are documented in the schema with defaults and constraints. The description adds only the high-level notion that savePath is optional, which repeats the schema's 'Optional file path' description. Baseline 3 applies when schema does the heavy lifting.

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

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

Specific verb+resource ('Capture a screenshot of the League Client window') with the mechanism named (CDP). Clearly distinguishes itself from siblings like lol_dom_query or lol_eval, which inspect state rather than produce an image.

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

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

No when-to-use guidance, no alternatives named, no conditions under which a screenshot is preferred over other inspection tools like lol_eval or lol_dom_query. The agent must infer that this is for visual capture.

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

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

No annotations exist, so the description carries the full behavioral burden. It implies a read-only enumeration via 'List' and names what is enumerated, but says nothing about permissions, whether the client must be running, freshness, or invocation cost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. The verb and resource come first and the parenthetical adds precision without padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should hint at the return shape (target identifiers usable by the other CDP tools). It names the target categories but not how results are keyed or consumed, leaving a gap for a discovery tool with several dependent siblings.

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

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

The tool takes zero parameters, so there is nothing to document beyond the empty schema. Baseline 4 applies; no additional parameter meaning is needed or missing.

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

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

Specific verb (List) plus a specific resource (CDP debugging targets) with a parenthetical enumerating the target kinds. An agent understands exactly what it returns. It does not distinguish itself from the CDP siblings (console_start, screenshot), so it falls short of a 5.

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

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

No explicit when-to-use framing, but listing active targets implies a discovery step before attaching to a target via lol_cdp_console_start, lol_cdp_screenshot, or lol_eval. That implication is left for the agent to infer rather than stated.

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

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

With no annotations provided, the description bears full disclosure burden. It reveals a key prerequisite (Pengu Loader's remote debugging port), describes the output format (tag, id, className, trimmed text, plus requested properties), and names a failure path. It doesn't explicitly say the operation is read-only, but querySelector semantics imply that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences with the core action front-loaded and the dependency/failure note appended. No filler or repeated schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Completeness is good for a 3-param query tool: it specifies the return description format (useful since there is no output schema), the runtime dependency, and the failure fallback. Minor gaps include pagination/limits on matches and the exact shape of returned objects, but nothing blocking a call.

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

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

Schema coverage is 100%, so the schema fully documents all, props, and selector. The description's 'plus any requested properties' aligns with the props param but adds no syntax or format details beyond what the schema already provides. Baseline 3 is appropriate.

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

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

States a precise verb+resource pair: runs document.querySelector(All) inside the client UI and returns match descriptions. This is unambiguous and clearly distinct from siblings like lol_get (generic get) and lol_eval (arbitrary JS execution).

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

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

The DOM-inspection purpose is self-evident, and it explicitly routes to lol_status as an alternative diagnostic if the remote debugging port fails. It doesn't enumerate when-not-to-use versus siblings like lol_eval, but the querySelector framing makes the intended use clear enough.

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

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

With no annotations, the description carries the burden of behavior. It discloses the case-insensitive substring filter behavior and the fields returned (verb, group, description). It does not specify the exact output format (e.g., array of objects) or pagination, leaving minor gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the primary purpose, and every sentence adds meaningful detail. The filter behavior is explained succinctly without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only listing tool with one optional parameter, the description is largely complete. It specifies what is returned (verb, group, description) and filter behavior. The absence of an output schema is partially mitigated by the described table structure, though exact JSON format is not stated.

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

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

The schema already provides the filter parameter and examples, but the description adds value by explaining case-insensitivity and the fields it matches (verb, path, group, description). This goes beyond the schema's basic description.

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

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

The title and description clearly state the tool lists curated LCU endpoints with verb, group, and one-line description. It is distinct from siblings like lol_get/lol_request that execute calls, and the phrase 'this project actually uses' clarifies scope.

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

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

The description implies the tool is for discovering the endpoints the project supports, which separates it from the call-execution tools. However, it does not explicitly mention when to use it vs. alternatives or provide exclusions, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses that evaluation bypasses the write allowlist by construction and is gated by allowEval, which is significant behavioral context. It also implies code execution capabilities. It does not mention error handling or side effects, but the key traits are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. It leads with the purpose, then adds a crucial behavioral note about bypass and gating. Every word earns its place, and the structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a potentially powerful evaluation tool with only 2 parameters and no output schema, the description adequately covers the return value and the prerequisite flag. It does not specify timeout or error behaviors, but those are minor gaps given the simplicity of the interface.

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

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

The schema already provides descriptive text for both parameters ('expression' and 'awaitPromise') with 100% coverage, so the description adds no extra parameter-level detail beyond what the schema gives. The recommended baseline of 3 applies.

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

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

The description clearly states the verb 'evaluate' and the resource 'expression in the client UI's own context', and notes that it returns the value. It also highlights the unique property of bypassing the write allowlist, which distinguishes it from other tools, though it does not explicitly name a sibling.

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

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

The description provides a gate condition (allowEval config flag) and points to lol_status for checking it, which is useful. However, it does not offer explicit when/when-not guidance relative to siblings like lol_get or lol_request, leaving the agent to infer when this tool is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job: it clarifies the cursor semantics, warns about the 'dropped' field indicating data loss from buffer wrap, and explains the 'truncated' field with a concrete remediation path via lol_get. This is strong transparency for a polling tool. It does not, however, state whether polling advances a cursor or clears the buffer (though 'plus the new cursor' implies advancement), and it omits any mention of side effects or read-only guarantees, which keeps it slightly below a perfect score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero fluff. It front-loads the primary function (return events since cursor), immediately explains the two special output fields (dropped, truncated) with actionable guidance, and stays tightly focused. Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a polling tool with 3 parameters and no output schema, the description covers the essential elements: the cursor mechanism, the dropped-event warning, and the truncated-data recovery path. It does not specify the full response shape (e.g., whether an empty array is returned when no events exist, or the structure of each event beyond its URI), but given the tool's complexity and the specific edge cases it does address, it is nearly complete for an agent to call correctly.

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

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

Schema description coverage is 100%, so each parameter already has a description in the schema. The description adds value by clarifying that 'since' acts as a cursor from the previous poll, aligning with the tool's sequencing logic. However, it does not add extra meaning for 'limit' or 'filter' beyond what the schema provides. Since the schema carries the heavy lifting, a baseline of 3 is appropriate.

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

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

The description states a concrete verb ('Return') and a specific resource ('buffered events') with a precise condition ('seq greater than since') and explicit output elements (new cursor, dropped, truncated). The name 'lol_events_poll' plus the clear behavior distinguishes it from siblings like lol_events_start/stop, and it even references lol_get for re-fetching truncated entries, reinforcing its role.

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

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

The description implies usage: it's a poll operation that drains buffered events, and it gives a concrete instruction to re-fetch truncated entries via lol_get. However, it does not explicitly state when to use this tool versus alternatives (e.g., only after starting event capture with lol_events_start), nor does it mention any prerequisites or exclusion conditions. The usage context is mostly inferable from the name and behavior, not explicitly described.

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

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

With no annotations provided, the description carries the full disclosure burden, and it delivers substantial behavior: it discloses the memory-risk side effect ('fills the buffer in seconds'), the ingest-time filtering behavior, and the idempotent re-call semantics (replaces filters, preserves buffer). Minor gaps: it does not state whether the buffer persists after stop or what teardown entails, but the operational warnings and re-call contract are meaningfully beyond what structured fields would convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly composed sentences with zero waste. The core action is front-loaded in sentence one, the filter guidance with its safety warning sits in sentence two, and the re-call behavior is the single remaining fact in sentence three. Every sentence earns its place and there is no redundancy with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-optional-parameter tool with no output schema and no annotations, the description is nearly complete: it covers the primary action, the parameter semantics with a concrete example, the risk of unfiltered use, and the idempotent re-call behavior. The only shortfall is no mention of return value or failure modes (e.g., LCU not connected), which is minor for a side-effect starter tool.

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

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

Schema coverage is 100% (the filters param is documented with pattern and example), so the baseline is 3. The description adds operational meaning beyond the mechanical definition: 'Filters are URI prefixes applied at ingest' clarifies timing, and the buffer-danger note explains why filters matter. This converts the parameter from a mere format spec into a functional design decision, exceeding the baseline.

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

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

The description states a precise verb and resource: 'Open the OnJsonApiEvent tap and buffer events in memory.' It clearly identifies this as the start/buffer action, distinguishing itself from siblings like lol_events_poll (retrieval) and lol_events_stop (teardown) without any ambiguity. The resource name and action are concrete and immediately actionable.

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

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

The description gives explicit guidance on the key usage decision — 'pass filters unless you truly want everything' — and explains the consequence ('the unfiltered firehose fills the buffer in seconds'). It also documents the re-invocation contract: 'Calling this while already running replaces the filters and keeps buffered entries.' It does not explicitly name sibling alternatives for routing, but the filter-or-not guidance and re-call semantics cover the core usage choices for this tool.

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

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

With no annotations provided, the description fully discloses the primary behavior (closing the tap) and a key side effect (buffered entries remain readable via lol_events_poll). It doesn't mention idempotency or behavior if called without a prior start, but those are minor for a stop operation. This adds value beyond what would be obvious from the name alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler. The primary action is front-loaded ('Close the event tap'), and the only additional detail (buffered entries remain readable) is essential context. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description fully covers what the agent needs: what it does and the key consequence. No missing information that would prevent correct usage. The simple nature of the operation means no additional context is required.

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

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

The tool has zero parameters, so the description correctly makes no mention of parameters. The schema is empty (100% coverage), and the baseline for 0-parameter tools is 4. The description provides no additional parameter guidance, but none is needed.

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

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

The description uses a specific verb ('Close') and a resource ('event tap'), which clearly distinguishes it from siblings like start and poll. It also states the outcome: buffered entries stay readable, removing ambiguity about its effect.

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

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

The description implicitly says 'stop buffering' and notes that buffered entries remain accessible, which tells the agent it's used after events have been started. However, it doesn't explicitly state when not to use it or mention any alternative, though the simplicity of the operation makes this acceptable.

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

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

No annotations exist, so the description carries the full burden. It discloses that it merges two event sources chronologically and what question it answers, which is useful behavioral context, but it omits key traits such as the prerequisite recordings, whether the operation is read-only, and how the three output formats differ.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tightly written sentence that front-loads the core action and the diagnostic payoff with no wasted words. Slightly dense but efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description must do more of the work. It does not explain where the source data comes from (requiring prior recording sessions), nor does it describe the narrative/events/summary output shapes, leaving meaningful gaps for a six-parameter correlation tool.

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

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

Schema description coverage is 100%, so all six parameters (limit, since, until, format, levels, uriPrefix) are already documented in the schema, including the enum for format and levels. The description adds no syntax or semantic detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description uses a specific verb+resource combination ("Combines WAMP recorder events and CDP console entries into a chronological timeline") and further states the diagnostic questions it answers. This is clear and distinguishable from recording/tailing siblings, though it never names the dump/tail tools it consumes.

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

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

Usage is only implied through the diagnostic framing ("whether the client emitted an event and where the frontend broke"). There is no explicit statement of when to reach for this over lol_wamp_record_dump or lol_cdp_console_tail, and no mention of the prerequisite that recorders must already be running.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return shape and states 'Always allowed', giving a safety hint. However, it does not describe error behavior, rate limits, or consequences of invalid paths. For a simple GET, this is partial coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The core action and return format are front-loaded, and the pointer to lol_endpoints is useful. Very efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter GET tool with no output schema, the description covers the essential aspects: what it does, what it returns, and how to find valid inputs (via lol_endpoints). It could mention error handling, but the delegation to lol_endpoints mitigates the need. Overall reasonably complete.

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

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

Schema description coverage is 0%, and the description does not explain the 'path' parameter in detail beyond 'any LCU path'. It points to lol_endpoints for discovery, which compensates somewhat, but the description itself adds little semantic detail about the parameter's format or valid values.

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

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

States a specific verb (GET), resource (any LCU path), and return shape ({ status, body }). Names a sibling (lol_endpoints) for discovery, which also helps differentiate its scope. The 'Always allowed' adds a constraint.

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

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

Gives some guidance: use lol_endpoints to discover paths, and 'Always allowed' implies no restrictions. However, it does not explicitly contrast with alternative tools like lol_request (likely for non-GET methods) or specify when not to use this tool. The guidance is implicit rather than explicit.

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

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

With no annotations given, the description carries the full burden of disclosing behavior. It specifies that GET/HEAD are permitted unconditionally, other verbs must match a write allowlist, and refusals return the exact config line needed to allow the request. This is a valuable behavioral disclosure that goes beyond the schema. It does not cover response format or error handling, but the core restrictions and refusal behavior are clearly stated, making it above average.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long and immediately front-loads the core action ('Send any HTTP verb to an LCU path') before explaining the allowlist nuance. There is zero wasted wording, and every clause contributes to the agent's understanding. This is a model of conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has three parameters, no output schema, and no annotations, the description adequately explains the allowlist constraint and refusal behavior. However, it does not mention expected response format, error handling, or the fact that paths are relative to the LCU API. These gaps could lead to incorrect invocations or misinterpretation of results, so while it is serviceable, it is not fully complete for a generic HTTP request tool.

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

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

The schema description coverage is only 33% (only 'body' has a description). The tool description adds very little parameter-specific meaning—it mentions 'any HTTP verb' but does not elaborate on acceptable path formats, the meaning of the parameters, or provide examples. Since the description does not compensate for the low schema coverage and fails to clarify the method/path semantics beyond the enum and pattern, it scores a 2.

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

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

The description clearly states the tool's function: sending any HTTP verb to an LCU path. This distinguishes it from siblings like lol_get, which presumably only handles GET requests, and lol_status, which likely queries status. The verb 'send' plus the resource 'LCU path' makes the purpose unambiguous.

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

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

The description gives clear usage context: GET and HEAD are always allowed, while other verbs require explicit allowlist entries, and it explains the refusal behavior. However, it does not explicitly mention when to use this tool versus a more specific sibling like lol_get, nor does it provide exclusions or alternatives. The allowlist rule essentially defines the usage boundary, earning a 4.

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

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

With no annotations, the description carries the full burden. It discloses that this is a terminate-and-restart mutation and that readiness can be awaited, but it omits side effects an agent should know: in-flight client state is lost, plugin/CEF context is destroyed, and there is no statement of permissions or failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the action front-loaded and the rationale trailing. Nothing needs trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-optional-parameter tool with no output schema and no annotations, the description supplies purpose, mechanism and use cases. It is only slightly thin on post-restart state and failure handling, which limits it below a 5.

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

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

Schema description coverage is 100%, so both waitForReady and timeoutSeconds are already fully documented, including defaults and the 2-60s range. The description adds nothing beyond that, which earns the baseline 3.

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

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

States a specific verb pair (terminates and restarts) and a precisely scoped resource (League Client UX / frontend CEF renderers) with the mechanism (via Riot Client). An agent can distinguish this from read-only siblings like lol_status or lol_cdp_targets immediately.

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

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

Gives clear when-to-use triggers: developing Pengu Loader plugins, or recovering from a frozen interface. It does not name an alternative or a when-not-to-use condition, but no sibling tool performs a comparable restart, so the routing risk is low.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Live' implies the spec is fetched from the running client rather than a static file, but the description does not state whether a fetch hits the network, whether results are cached, refresh cost, or that it is a read-only operation. For a zero-annotation tool this leaves important behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single well-formed sentence, front-loaded with the intent. No padding or repetition, though it could have used a second clause to route the agent to alternatives.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description must carry more weight, yet it does not describe the shape of results (endpoint list vs. single signature vs. model definition) or how the optional filters combine. Adequate for basic invocation but incomplete for an introspection tool.

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

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

Schema description coverage is 100%, so all four parameters already have clear descriptions with examples (e.g. path '/lol-lobby/v2/lobby', model 'LolLobbyLobbyDto', method enum). The description adds nothing beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Inspect') and a concrete resource set ('LCU API endpoint signatures, parameters, request bodies, and models'). An agent understands what the tool returns, but nothing distinguishes it from siblings like lol_endpoints or lol_get, which plausibly overlap in the discovery space.

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

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

There is no when-to-use or when-not-to-use guidance. 'the client's live OpenAPI/Swagger v2 specification' hints that it is a discovery/introspection step, but the description never says to call it before crafting lol_request calls, nor how it relates to lol_endpoints or lol_get.

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

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

Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It explains what the tool reports (subsystem health, event tap state, config) but does not explicitly state whether it has side effects or is read-only. Given the 'status' nature, it's implied to be non-mutating, but this is not stated outright, leaving some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The first sentence front-loads the core function (what health is reported), and the second provides usage guidance. Every word earns its place, and the structure is efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a status/diagnostic tool with no output schema, the description adequately covers what is reported (LCU, CDP, event tap, config) and when to use it (first when other tools fail). It omits the exact return format, but that is not explicitly required since there is no output schema. It is sufficiently complete for an agent to invoke it correctly.

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

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

The tool has zero parameters, so the description need not elaborate on parameter usage. Per the rubric, a tool with no parameters gets a baseline of 4 regardless of schema coverage. The description does not need to add any parameter-related information.

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

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

The description clearly states that the tool reports the health of both LCU and CDP subsystems, event tap state, and effective config. It identifies distinct resources and a clear purpose (health check) that distinguishes it from sibling action-oriented tools like lol_get or lol_eval. However, it lacks an explicit verb like 'get' or 'check', making the action implicit rather than direct.

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

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

The description explicitly says 'Call this first when another tool fails', providing a precise condition for when to use it. This gives clear contextual guidance and implies it is a diagnostic first step, effectively routing the agent away from alternatives in failure scenarios.

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

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 stats are cumulative and survive buffer eviction, that a non-zero 'dropped' means post-cursor eviction, and that lifecycle entries survive a uri filter. It stops short of stating permissions, read-only nature, or whether cursor state mutates, leaving some behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with the core return value and followed by the non-obvious semantics (eviction, filter interaction, time units). Every sentence adds information; nothing is redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly explains the return shape (timeline plus per-URI stats) and the meaning of key fields like stats and dropped. Combined with a fully documented 6-parameter schema, it is nearly complete; only the pagination/limit interaction and read-only confirmation are left implicit.

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

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

Schema coverage is 100% so baseline is 3, but the description adds genuine semantics beyond the schema: the interaction between 'uri' and 'kinds' (lifecycle entries survive a uri filter, only kinds exclude them), the meaning of a non-zero 'dropped' relative to the cursor, and clock comparability of timestamps. This meaningfully enriches the parameters.

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

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

States a specific verb and resource: 'Return the recorded timeline plus per-URI stats.' The resource ('recorded WAMP timeline') is unique against siblings lol_wamp_record_start/stop, making it clear this is the retrieval counterpart to recording. No ambiguity about what it produces.

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

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

Usage is implied by the pairing with lol_wamp_record_start/stop, and the cursor/dropped semantics hint at polling behavior, but there is no explicit 'use this when...' or exclusion against alternatives like lol_events_poll. An agent can infer the context but is given no routing guidance.

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

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

With no annotations, the description carries the behavioral burden well: it discloses that a second independent socket is opened, that every frame plus lifecycle events (open, close code, error, reconnect gap) are recorded into one timeline, and that double-start is an error. It stops short of stating resource cost, permission needs, or that uris must begin with '/'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and scoping constraint in the first sentence, and each subsequent sentence justifies a parameter or the error path. It is dense with nested quoted examples and escaped inner quotes, which makes it slightly harder to parse than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or annotations, so the description must stand alone, and it does for what the tool does and how to start it. Retrieval of the recorded timeline is delegated to the sibling dump/stop tools, so no critical gap remains for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantic value: uris 'reproduces what a page-side plugin sees' and cannot distinguish socket death, and restart explicitly 'discard[s] the old [recording]'. That is decision-relevant meaning beyond the schema.

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

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

Specific verb+resource ('Start recording LCU WAMP traffic') with an explicit scope statement that it opens a second WAMP socket independent of lol_events_*. An agent can distinguish it from lol_events_start, lol_wamp_record_stop and lol_wamp_record_dump without opening any schema.

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

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

Explicitly states the default (firehose) and the alternative (passing uris), plus the diagnostic trade-off that selects between them: firehose lets you tell 'socket died' from 'nothing happened', per-URI cannot. It also states the error condition when a recording is already running and names the remedy (restart).

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

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

With no annotations, the description carries the full burden and it does disclose one important trait: the recorded timeline persists and stays readable afterward, so stopping is non-destructive. It omits other behaviors that matter for a state-mutating call, such as whether it errors when no recorder is active or whether it flushes buffered data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, and the core action is front-loaded ahead of the follow-up pointer to the dump tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, no-output-schema toggle, the description covers the essential agent concern: that stopping doesn't lose the recording. It leaves only minor gaps around error/prerequisite conditions.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond the schema's empty object.

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

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

The verb+resource are concrete: 'Close the recorder socket' maps unambiguously to stopping capture, and the reference to lol_wamp_record_dump distinguishes it from the sibling that reads the timeline. It never explicitly says it halts LCU WAMP traffic capture (that comes from the name/title), so it stops just short of a 5.

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

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

It routes the agent to lol_wamp_record_dump for reading recorded data, which is useful implied guidance, but it never states when this tool should be used (e.g., after lol_wamp_record_start) or what happens if nothing is recording. Usage is implied rather than spelled out.

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