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

Annotations only provide readOnlyHint=false, so the description carries meaningful extra burden. It discloses that the element is scrolled into view, that results are reported as overlays/nav/LCU requests, and that dangerous writes are blocked at the network level, which is valuable behavioral context beyond annotations.

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 dense sentences with no filler. The core action is front-loaded, followed by the key reporting and safety behavior, so every part 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?

Given 11 optional parameters, no output schema, and sparse annotations, the description does a good job covering the click's side effects and safety blocking. It could say more about how targeting parameters interact or when a click is expected to fail, but it is broadly 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 high at 91%, so the schema already documents parameters like ref, text, selector, and force. The description does not add targeting semantics beyond saying the click is on an element, so 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 specific verb and resource: a real CDP mouse click on an element, scrolled into view. The 'CDP Input' qualifier distinguishes it from script/eval-based synthetic clicks and makes the action 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?

Usage is implied by the emphasis on a 'real mouse click', but the description does not explicitly say when to choose this over siblings like hover, script, or eval. The blocked-write context helps set expectations but is not a use-vs-alternative rule.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds two useful traits beyond that — the window is only 'recent' messages, and uncaught exceptions are included alongside logged messages. It says nothing about ordering, pagination, or whether the buffer is cleared on read, so the added context is modest.

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 resource and scope appear immediately. It is efficient, though the brevity comes at the cost of any parameter or behavioral detail.

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 two-parameter read tool with no output schema and a readOnlyHint, the description is adequate at the top level. However, it leaves the filter and limit semantics completely unexplained, which is the main thing an agent needs in order to call 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?

Schema description coverage is 0% and there are two parameters, limit and filter, neither of which the description mentions. An agent cannot tell from the text whether filter matches message text, severity level, or source, nor what limit defaults to — the description does not compensate for the coverage gap.

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?

Names a specific resource (console messages plus uncaught exceptions) from a specific source (the client page), which is enough to tell it apart from siblings like network or metrics. It is a noun phrase rather than a verb, but the retrieval intent is 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?

There is no statement of when to reach for this tool versus alternatives such as network, metrics, state, or eval. The agent must infer that console diagnostics belong here and network/errors elsewhere, with no exclusions or prerequisites given.

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?

Annotations only declare readOnlyHint=false, so the description carries most of the burden and does it well: it discloses where the style lands (document head), that styles are keyed by id, and the significant shadow-DOM limitation with a suggested workaround. It doesn't say what happens when a style with the same id already exists, which is the main remaining behavioral gap.

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 core action and its inverse, followed by a clearly flagged caveat. Nothing is wasted and the limitation note 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?

With no output schema and only a readOnlyHint of false, the description covers placement, idempotency-by-id, and the shadow-root caveat, which is enough to call it correctly. Minor gaps remain on overwrite semantics and the persist parameter, but the schema covers persist.

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 only 25% (just persist), so the description must compensate. It explains the id keying and the remove=true toggle, effectively documenting two of four parameters, but leaves css and the interaction of persist with reloads to 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?

The description uses a concrete verb and resource ('Adds ... a <style> in the document head under an id') plus the removal variant, so an agent immediately knows what the tool does. It is distinguishable from siblings like script or eval, though it never names them explicitly.

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 rather than stated: 'Adds (or with remove=true removes)' shows the two modes, and the shadow-root note tells the agent when this tool won't work. There is no explicit when-to-use-vs-alternatives guidance for injecting styles versus using script/eval.

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?

The annotation only declares readOnlyHint=false, and the description is consistent with that (arbitrary JS execution is not read-only). It adds genuinely useful behavioral context — promises are awaited and the result is JSON — but omits side-effect warnings, what happens on timeout (error vs partial result), and any execution-context restrictions. For an arbitrary-code tool that is a notable gap.

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 short sentences, front-loaded with what the tool does, then input format, then the plugin-API affordance. No filler and every clause carries information an agent can act on.

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 does state the return is a JSON result, which covers the basics. But for a high-power eval tool with a mutating annotation and no sibling differentiation, it should also cover timeout/error behavior and clarify its relationship to `script`; those omissions matter given the tool's blast radius.

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?

At 50% schema coverage, `code` is undocumented in the schema, and the description compensates well by explaining the accepted forms (expression or async IIFE) and that promises resolve. The second parameter, `timeoutMs`, is covered only by a terse schema default and gets no mention in the description, leaving the coverage gap half-closed.

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 names a specific verb and resource ("Runs JavaScript in the client page") plus the return shape ("returns the JSON result"), so the agent knows exactly what the tool does. It does not, however, distinguish itself from the sibling tool `script`, which plausibly overlaps — an agent must guess which one to reach for.

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 gives useful authoring guidance — "Wrap statements in an async IIFE or just write an expression; promises are awaited" — which tells the agent how to format input. But it never says when to prefer this over `script`, `query`, `state`, or `lcu`, nor when to avoid it, so the selection decision is left implicit.

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?

Adds real context beyond the lone readOnlyHint=false annotation: it discloses that the mouse is moved "real"-ly (native input events, not synthetic dispatch) and that the call waits for and reports tooltip/flyout appearances. It stops short of saying what happens when no tooltip appears or whether hovering can trigger page handlers.

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?

One sentence, zero padding, with the mechanism front-loaded before the reported outcome. Nothing could be cut without losing meaning.

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?

Reasonable for a 9-param tool with no output schema: the description covers the mechanism and the kind of result returned. It is slightly thin on what a no-tooltip result looks like and on the default timeout, both of which an agent would want to know.

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?

All 9 parameters are fully documented in the schema (100% coverage), so the description needn't repeat them. It says nothing about the multiple element-targeting strategies (ref/text/selector/x,y) or the default wait, leaving the schema to carry that weight – 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 and mechanism ("Moves the real mouse over an element") plus the outcome ("reports tooltips/flyouts that appeared"), which separates it from click/type/scroll siblings without naming them. It's clear what it does, though it never explicitly contrasts itself with `click` or `query`.

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: an agent can infer this is the tool for revealing hover-only UI like tooltips and flyouts. There is no explicit when-to-use guidance, no mention of prerequisites, and no named alternative for cases where hovering fails.

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 only readOnlyHint=false, the description legitimately adds value by disclosing that a specific combo (Ctrl+Shift+F12) toggles the ReimaginedLC layer. However, it doesn't state what pressing keys affects generally, failure behavior, or return values, so the added behavioral context is limited.

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 sentence front-loads the action and follows with illustrative examples; every clause earns its place. Only the inline meta-comment about the ReimaginedLC toggle slightly crowds the format examples.

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 one-parameter tool with no output schema, the description is mostly adequate, but with minimal annotations it leaves return behavior and error semantics unspecified. It covers the input format but not the observable effect of the 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 0% for the single 'combo' parameter, so the description must carry the burden. It does so well by giving six representative examples ('Escape', 'Ctrl+A', 'Ctrl+Shift+F12') that convey the expected key/combo format, though it doesn't address case sensitivity or key-name conventions.

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 names a specific verb ('Presses') and resource ('a key or combo on the page') with concrete examples of valid input. It effectively distinguishes itself from a text-entry sibling like 'type' by emphasizing key combos, though it never names an alternative explicitly.

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 guidance on when to use this tool versus 'type', 'click', or 'script', nor any prerequisites or exclusions. The examples imply input format but convey nothing about choosing this tool over siblings.

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?

The annotations only declare readOnlyHint=false, so the description adds substantial value by stating that auth is handled and that specific dangerous writes are refused. It still does not describe behavior for allowed writes, error responses, or side effects, but the safety disclosure is strong.

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 tight sentences with no wasted language. The core purpose and auth handling are front-loaded, followed by the important refusal constraint.

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 generic mutating API caller with no output schema and incomplete parameter documentation, the description covers purpose, auth, and write refusals but omits return behavior, allowed-write side effects, and error semantics. It is adequate for selection but incomplete for confident 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 only 50%, and the body parameter has no type or description in the schema. The description does not explain body semantics, method usage, path expectations, or maxChars behavior, so it does not compensate for the missing schema documentation.

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 specific action and resource: it calls the LCU API from inside the client. It also adds a meaningful safety boundary by listing dangerous writes that are refused. It does not explicitly distinguish itself from sibling tools such as lcu_endpoints or query, so it stops 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?

The refusal list implies some when-not-to-use conditions for dangerous writes, but the description gives no explicit guidance on when to choose this tool over lcu_endpoints, query, or network. Usage is implied by the LCU API framing rather than stated as 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?

Annotations already declare readOnlyHint=true, so safety is covered; the description adds genuine non-obvious behavior: the catalog is derived from /help on first use and cached per patch, telling the agent to expect a cold-start cost and patch-scoped freshness. It stops short of describing result size, ordering, or how `limit` is applied.

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 tight sentences with the core action and the matching rule front-loaded, plus the caching note as a parenthetical. No filler and nothing that repeats 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 read-only search over 3 params with no output schema, the description covers the data source, freshness, and matching semantics but omits what a result looks like and what the two optional params do. Adequate to invoke, not fully self-contained.

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 only 33%, so the description must carry weight; it explains the required `query` (AND-matching over path/function-name tokens) which the schema only illustrates by example. However, `limit` and `method` are left completely undefined in both schema and description, so the compensation is partial.

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: it searches the LCU endpoint catalog of the installed client. That is clearly distinct from the visual/navigation siblings, though it never distinguishes itself from the sibling `lcu` (which presumably invokes an endpoint rather than searching for one), leaving the search-vs-call split implicit.

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 statement of when to use this versus the `lcu` sibling or any alternative, and no prerequisites. The only guidance is a matching constraint ("Every word must match the path or function name"), which governs how to phrase a query, not when the tool is the right choice.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower, and the description still adds genuine context: this is crawled data, blocked buttons surface the dangerous endpoint they would have called, and how requests are attributed to controls. It omits freshness (when the crawl was taken), result size, and whether the map is live or static — the main behavioral unknowns for a read-only crawl.

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 content is front-loaded and every clause carries information; nothing is filler. The opening sentence is a long, dense run-on, but the follow-up sentence cleanly enumerates the parameter modes.

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 schema descriptions, the definition does a fair job describing what data exists, but leaves it unclear how results are shaped and sized, how large a full screen dump is, how deep `query` searches, and whether the crawl is current. For a tool whose primary use is deciding whether to click something, that leaves meaningful unknowns.

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 0% with two bare string parameters, so the description carries the full burden — and it does, mapping each parameter to a distinct behavior (absent = screen list, `screen` = full detail, `query` = search across labels, hovers and endpoints). It stops short of saying what form `screen` takes (name vs. id) or what query matching semantics are used, which leaves one ambiguity.

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 resource — a crawled map of the native client covering screens, controls, hover text, click effects and fired LCU requests — which is far more specific than the bare name 'map'. It does not, however, distinguish itself from siblings that sound overlapping (snapshot, state, and especially the sibling literally named `query`, which also appears as this tool's parameter name).

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 clearly explains the three invocation modes (no args = list screens, `screen` = one screen in full, `query` = search labels/hovers/endpoints), which is real guidance. But it never says when to reach for this tool versus snapshot, query, css or eval, and never states the intended workflow (e.g. look up a control here before calling click). Usage is implied, not directed.

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?

readOnlyHint=true already establishes that this is a safe read. The description adds the specific counters returned (JS heap, nodes, layout/style recalcs, script duration), which is useful context, but says nothing about snapshot timing, cost, or whether values are cumulative vs instantaneous.

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?

It is a single short sentence fragment with no filler, but the missing verb and lack of front-loaded action make it less usable than it is short. Conciseness here shades into under-specification.

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 is the only place the return content is described, and the parenthetical list does that minimally. It does not convey the shape of the response (object keys, units, or whether metrics are zero-cost to collect), which an agent needs to use the result 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 takes zero parameters, so per the baseline this starts at 4. Nothing in the description is needed to explain inputs, and it doesn't waste space doing so.

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 names the resource (renderer performance counters) and enumerates what it covers, but gives no verb, so the agent must infer that the tool retrieves them. It also fails to distinguish it from close siblings like state and snapshot, which plausibly also expose runtime diagnostics.

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 statement of when to call this instead of state, snapshot, or console. The agent gets no signal about whether this is for performance profiling, debugging, or health checks.

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?

Annotations only declare readOnlyHint=false, so the description must carry the load; it usefully points to `state` and `map` as sources of valid ids. It does not disclose what happens after navigation (does it wait for the screen to load?), what occurs with an invalid id, or whether the current screen state is lost.

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?

One front-loaded sentence stating the action, followed by a tight parenthetical of examples and cross-references. No filler, and the most important fact (what `to` accepts) comes first.

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 one-parameter tool with no output schema, the main gap an agent would hit — where valid ids come from — is covered via `state` and `map`. Only the post-navigation behavior (loading/awaiting) is left unstated.

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 0% with a single opaque `to` parameter, so the description must compensate — and it does, enumerating concrete example ids ('rcp-fe-lol-collections', 'rcp-fe-lol-loot', 'home'...) and the two identifier namespaces. It stops short of saying whether ids are case-sensitive or how the two namespaces are distinguished.

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 ('Goes to a screen') and immediately clarifies the kind of identifier it consumes, which distinguishes it from generic click/hover tools. Lacks explicit naming of siblings it replaces, so not 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?

Implies direct navigation using either a Riot nav tab id or a crawl-map screen id, and points at `state` and `map` for valid values. However, it never states when to prefer this over clicking through the UI, nor any preconditions or failure behavior.

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?

readOnlyHint=true is consistent with a log read, and the description adds genuinely non-obvious behavior: asset requests are filtered out, results are ordered newest last, and blocked requests are retained. It does not disclose how far back 'recent' reaches, whether the log is truncated or capped, or how the limit interacts with retention.

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?

One dense sentence with no filler, and the identifying content (LCU requests by the client page) is front-loaded before the qualifiers. It is slightly telegraphic, packing exclusions and ordering into parentheticals rather than giving them structure.

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 low-complexity read tool with no output schema, the agent still lacks the shape of an individual entry and what 'recent' means in practice, plus any hint about `limit`. The core intent is conveyed, but a few operational details an agent needs are absent.

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 50%: `filter` is documented as a method/path substring, but `limit` has no description and a nonsensical ±9e15 range. The description compensates for neither — it never mentions paging, defaults, or how the filter matches, leaving half the parameters unexplained.

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 names a concrete resource (recent LCU requests made by the client page) with clear scope qualifiers: assets excluded, newest last. An agent can tell this is a request-log retrieval rather than an endpoint catalog or console dump, though it never explicitly contrasts with siblings like `lcu` or `lcu_endpoints`.

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 — an agent infers this is for inspecting what traffic the page issued (including blocked requests), which hints at debugging the safety guard. There is no explicit when-to-use or when-to-prefer-`lcu`/`lcu_endpoints` guidance, so selection still requires inference.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds useful return-shape context (label, selector, box, state, optional text/HTML, shadow-root traversal), but never mentions what happens with 'all' (counting matches) vs a single element, or the behavior when nothing matches.

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?

It is a single front-loaded sentence with no filler, but its brevity comes at the cost of under-specification: the ten-parameter targeting model is never summarized, so the terseness is not fully 'earning 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 10-parameter tool with four alternative targeting modes (ref, selector, coordinates, text) plus all/nth and show modes, and no output schema, the description should explain the targeting precedence and what 'all' changes. It covers only the return fields, leaving the core invocation model to the schema.

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 explains x/y, all, nth, ref, text, exact, within, and selector. The description only echoes the shadow-root inclusion for selector and the optional text/HTML output. Baseline 3 is appropriate when the schema carries the parameter burden.

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 phrase 'Details of one element: label, selector, box, state, and optionally its text or HTML' communicates that it retrieves a single element's details, but it is a noun phrase without a verb and never says how an element is targeted (ref, selector, text, coordinates). It also doesn't distinguish this from siblings such as 'snapshot', 'css', or 'state', which likely also expose element structure.

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 at all: nothing says whether to prefer this over 'snapshot' for inspection, or 'css' for selector lookups, or 'state' for element state. The only hint ('Most reliable' appears in the schema, not the description) is absent from the description text itself.

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?

Beyond the readOnlyHint=false annotation, it discloses two behaviors an agent could not infer: the operation is refused in specific game states, and the call blocks until the Riot UI is restored. Both are critical for planning around latency and failure, and neither is stated in structured fields.

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 short sentences in priority order: what it does, when it fails, and that it blocks. No filler, and the most decision-relevant constraint (refusal states) is not buried.

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 action with no output schema, the description covers invocation, refusal conditions, and completion semantics ('waits until the Riot UI is back'). It does not say what is returned on success or how a refusal surfaces to the caller, which would complete the picture.

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 and the schema is empty, so there is nothing to disambiguate; baseline 4 applies. The description correctly avoids inventing parameter detail that does not exist.

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 ('Reloads the client page'), which is unambiguous and distinct from sibling actions like navigate, state, or snapshot. The parenthetical reference to an external tool is less useful than naming a sibling, so it stops 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?

Explicitly enumerates the six states in which the call is refused (Matchmaking, ReadyCheck, ChampSelect, GameStart, InProgress, Reconnect), which is a concrete when-not-to-use rule an agent can act on. It does not point to an alternative action for those states, so use guidance is clear but not complete.

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?

Annotations already declare readOnlyHint=true, so the safety bar is low. The description usefully adds the pixel-to-CSS-px mapping behavior, but does not disclose default image format, what happens when 'save' is used, or how multiple candidate elements are resolved.

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 core capability is stated first and the coordinate-mapping caveat follows immediately.

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 leaves the return value only implicit ('Screenshot' implies an image) and does not say what is captured when ref/text/selector are omitted versus combined. Adequate for a tool whose parameters are well documented, but not fully self-contained.

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 86%, so the baseline is 3. The description earns a bump by explaining the 'scale' parameter's meaning in operational terms (one image pixel = one CSS px at the default), which is the least obvious parameter in the set.

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?

Names a specific verb+resource ('Screenshot of the client') and clarifies scope: whole client or a single element. It is distinguishable from the DOM-oriented 'snapshot'/'query' siblings, though the description never explicitly contrasts them.

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 a concrete usage rule: at default scale, image coordinates can be fed to click/hover as x/y. That implies when this tool is useful (visual grounding before clicking), but there is no explicit guidance on when to prefer screenshot over snapshot, or what to do when scale is not 1.

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?

Annotations only declare readOnlyHint=false; the description supplies the material behavior an agent actually needs: registration is persistent across reloads only while the server is connected, and removal does not undo already-applied effects until a reload. That is exactly the kind of side-effect detail annotations cannot carry.

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?

One dense sentence with the primary behavior front-loaded and the flag semantics trailing in order of importance. No waste, though the parenthetical/unregister clause is slightly crammed and could be split for scan-ability.

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?

All four parameters are optional and no output schema exists, so the description is not required to explain returns. However, with 0% schema coverage and an unaddressed 'id' parameter and no statement of what registration returns, an agent can still mis-invoke with ambiguous argument combinations.

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 0%, so the description carries the full burden. It explains the 'remove' and 'list' flags and implies 'code' is the script body, but never defines 'id' beyond 'shows ids', nor what happens when id and code are combined or when neither is supplied.

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 ('Registers JavaScript') plus the key scope ('runs now and on every page load while this server is connected'), which distinguishes it from the one-shot sibling 'eval'. It never names eval directly, so the differentiation is implied rather than explicit.

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?

Covers the tool's own modes ('remove=true unregisters it', 'list=true shows ids'), which is real usage guidance, but gives no guidance on when to choose this over siblings like eval or reload, nor any prerequisites. Usage context 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?

The only annotation is readOnlyHint=false, which conveys no mechanism. The phrase 'real mouse wheel' is genuinely additive: it tells the agent this dispatches trusted wheel input (triggering real wheel listeners, lazy-loading, smooth-scroll behavior) rather than a programmatic scrollTop change. The deltaY sign convention is also disclosed. It stops short of noting that the viewport/state is mutated or how deltas are interpreted.

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?

One sentence, front-loaded with the action, with the directional convention parenthesized as a secondary detail. 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?

With 10 parameters, no output schema, and near-zero annotation coverage, the description leaves real gaps: delta units/magnitude are unstated, and 'over an element' implies a target even though every element-addressing parameter is optional (only deltaY is required), so the no-target behavior is undefined. Adequate but with clear holes.

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 80%, so the baseline is 3, but deltaX/deltaY are the two undocumented parameters and the description supplies the missing meaning for the required one ('deltaY > 0 scrolls down'), including that it is a real wheel delta rather than a CSS offset. The remaining element-targeting parameters are adequately covered by 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?

The description pairs the specific verb 'scrolls' with the mechanism ('real mouse wheel') and target ('over an element'), which separates it cleanly from click/hover/type/key siblings. It does not name a sibling explicitly, but the action is 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?

Usage is only implied: the agent can infer you call this to scroll a page or container, and 'over an element' hints at element targeting. There is no statement about when to prefer this over eval/script, and no note about what happens when no element is supplied.

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?

Beyond the readOnlyHint annotation, the description discloses genuinely non-obvious behavior: shadow DOM traversal, that repeated items (grids, lists) are collapsed after a few, and that refs go stale after screen changes. The staleness warning is the kind of operational caveat an agent cannot infer from the schema and would otherwise get wrong.

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, front-loaded with what the tool returns, then the ref contract, then the staleness caveat. Every clause carries information an agent needs; nothing is restated from the schema or annotations.

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 still conveys the shape of results (elements with refs, optional selectors via schema) and the safety profile is covered by readOnlyHint. Minor gap: it doesn't say what an element entry looks like beyond the ref, or how truncation is signaled in the response.

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 `max`, `within`, `collapse`, and `selectors` are already documented in the schema. The description only reinforces the collapse concept ('repeated items collapse after a few') and does not explain `within`, `selectors`, or the interaction between `max` and `collapse`. 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 specific verb and resource (lists visible interactive elements) with concrete examples (buttons, tabs, inputs, cards, nav items) and a distinguishing technical detail (pierces shadow DOM). It also names the return contract — each item carries a ref usable by click/hover/type/query — which separates it cleanly from those sibling action tools.

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 lifecycle rule: 'Take a new snapshot after the screen changes: refs go stale,' which tells the agent when to re-invoke rather than reuse stale refs. It also implicitly routes to click/hover/type/query as the consumers of its output. No explicit when-not-to-use or named alternative (e.g. vs. `state`) is 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?

readOnlyHint=true already declares the safety profile, so the description's job is lighter. 'Where the client is right now' adds a freshness/live-read implication, but nothing about cost, size of the response, or whether it blocks on a loading client — useful context that is missing.

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 dense enumeration plus a short imperative, with the key fields front-loaded. The field list is run-on but every item is informative and 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?

With no parameters, no output schema, and only a readOnly annotation, the description carries the burden of saying what comes back — and it does, field by field. What is missing is the relationship to 'snapshot' and any note on response shape or freshness.

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?

Zero parameters, so there is nothing to document; baseline 4 applies. The description correctly frames the tool as taking no input.

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 names a specific resource and enumerates its contents (gameflow phase, patch, nav tab, overlays, viewport), which removes ambiguity from the bare name 'state'. It does not distinguish itself from the sibling 'snapshot', which sounds like an overlapping read of the same client.

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?

'Start here' gives a clear entry-point signal but implies rather than explains usage. There is no statement of when to prefer this over 'snapshot' or 'query', and no exclusions.

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?

The description adds real context beyond the readOnlyHint=false annotation: it discloses that typing mutates page state and that a supplied target is focused first. It does not say whether existing content is preserved by default (the `clear` flag implies it is), nor how target resolution behaves if multiple match.

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 zero filler. However, for an 11-parameter tool, the available space is under-used rather than economically used, which keeps it off a 5.

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?

The tool has 11 parameters and no output schema, and the description never explains how the distinct target strategies (ref, selector, text, x/y) interact or which is preferred. It is minimally viable but leaves an agent to infer the core addressing model from the schema alone.

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 91%, so the schema already documents nearly every parameter, including `ref`, `selector`, `text`, `clear`, and `enter`. The description adds only the implied notion of an optional "target" and focus behavior, which is marginal over the schema 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?

States a specific verb and resource ("Types text into an input") that an agent can distinguish from `key` (key presses) at a glance. It does not explicitly name the sibling alternatives, so it stops 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 guidance on when to prefer this over `key` for pressing Enter, over `click` for focusing, or what happens if no target is supplied. The parenthetical only describes an internal behavior, not a usage condition.

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?

Annotations declare readOnlyHint=true, and the description is consistent with a non-mutating poll. It discloses the appear/disappear duality, but says nothing about blocking duration, whether it polls, or what happens on timeout even though timeoutMs is a parameter.

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 short sentence, front-loaded with the core action and the only modifier that changes semantics. 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?

Ten parameters, a 10s default timeout, and no output schema — yet the description never states what a successful wait returns (element? ref?) or how failure is surfaced. For a blocking tool with no output schema, an agent cannot infer result handling from the description alone.

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 90%, so the schema carries most parameter meaning and the baseline is 3. The description does add meaning for 'gone', the one parameter with no schema description, by tying it to disappearance, but says nothing about locator precedence (ref vs selector vs text) across the other nine.

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 ('waits until an element appears') plus the inverse condition via gone=true. It is clearly distinct from query/snapshot/state siblings because it blocks until a condition holds, though no sibling is named explicitly.

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 only guidance is 'or disappears with gone=true' — a parameter note, not usage guidance. Nothing says when to prefer wait_for over query or snapshot, when it is unnecessary, or what to do after it resolves.

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