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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral detail beyond them: indexing under pcall, never invoking f_* functions, array sampling with [] notation, and seeds embedding known names to detect removed entries. It does not explain the script's execution path or how output reaches gen/log.txt, so it falls short of a 5.

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 information is front-loaded with the core effect first, but it is a dense run-on paragraph mixing parenthetical asides, semicolon clauses, and inline examples. It earns most of its length for a 10-param tool, but structure and scannability suffer.

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 tool with 10 parameters, no output schema, and 0% schema coverage, the description does well on the switches it covers but omits five parameters and never clarifies what the tool actually returns (the script text) versus what it writes. Adequate for a first call but incomplete for confident use.

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%, so the description must carry all parameter meaning, and it only explains 5 of 10 params (root, space, seeds, compact, array_sample). `depth`, `max_nodes`, `raw`, `autorun`, and `to_table` are undocumented anywhere, leaving half the surface opaque.

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 artifact (a Lua script for the dev console/dev-mode mod) and its concrete effect (dumping the `root` API tree into gen/log.txt as WSDUMP lines). It also names the sibling it feeds into ('Then call import_api_dump'), so an agent can place it in the workflow. The verb is partly implied by the tool name rather than stated outright, keeping it 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 description supplies a clear next step ('Then call import_api_dump') and explains the `root`/`space`/`seeds`/`compact` switches, which implies when each is useful. However, it never says when to reach for this tool versus alternatives like search_api, api_index_status, or read_log, so selection guidance is left to 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value by enumerating the status fields reported, but says nothing about cost, caching, or failure modes when no dump is present.

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 core question (which index is active) before the detail list. The enumeration is dense but every item is a distinct reported fact, 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?

With no input parameters and no output schema, the description must convey the return shape, and it does so by listing the reported facts. It is adequate for a simple read-only status tool; only the staleness comparison logic against engine-version.txt is 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?

The tool takes zero parameters, so the baseline is 4; the schema carries no semantics that the description needs to compensate for.

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?

It names a specific resource (the active API index) and enumerates exactly what the report covers: live dump vs bundled, engine version, entry counts, imported dumps, staleness. That is clearly distinguishable from search_api, api_dump_script, and import_api_dump, 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?

Usage is only implied – an agent can infer this is a diagnostics call to run when API results look wrong or after importing a dump, but the description never states when to call it or how it differs from game_info or diff_game_versions.

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 mark readOnlyHint=false and idempotentHint=true; the description adds real behavioral context that explains those flags: it takes a new snapshot first if the game changed, and it writes the full diff to the data folder (diffs/). That is a genuine side effect disclosure beyond the annotations, though failure modes are not 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?

Front-loads the core purpose, then the accepted parameter forms, then the side effects. Dense but every clause carries information; only the parenthetical section enumeration is slightly list-heavy.

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 supplies the return shape (the section list) and where the artifact lands, plus the snapshot side effect and the single-snapshot explanation. The unexplained limit parameter and lack of error/edge behavior keep it from being fully 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%, so the description must carry all parameter meaning. It does well for a/b (snapshot id, id prefix, engine version; default previous vs latest) but the third parameter, limit (default 100), is never explained, leaving a third of the surface undocumented.

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 (structured diff) and resource (two game version snapshots) and enumerates the diffed sections (files, unit types, build rules, researches, auras, overrides, API index), which is far more than a tautology. It does not explicitly differentiate itself from the sibling diff_mod, 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?

Explains the default behavior (previous vs latest) and the accepted forms for a/b (snapshot id, id prefix, engine version), plus the single-snapshot edge case. It never names the alternative diff_mod as the choice for mod-vs-mod comparison, so the when-not-to-use side is missing.

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 the safe read-only, idempotent, non-destructive profile, so the description's job is to add semantics. It does, disclosing the default comparison pair, the draft-vs-published behavior, and the modsStorage/draft location, which is useful beyond the 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 tight sentences with the primary default behavior front-loaded and the draft variant following. 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 6-parameter read-only tool with no output schema and zero schema coverage, the description covers the core comparison semantics but omits any meaning for 'kind' and 'context', leaving an agent guessing on two parameters.

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%, so the description must carry parameter meaning. It explains v1, v2 defaults and the draft flag, but leaves 'kind' (default lua) and 'context' completely unexplained, so it only partially compensates 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?

States a specific verb+resource: computes a unified diff between two cached versions of a mod, with default scope (previous vs latest) named. It implicitly differentiates from the sibling diff_game_versions by scoping to mods, though it never names that sibling 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?

Gives clear context for the default mode (previous vs latest) and the alternate mode (draft=true compares published v1 against the developer-mode draft), including where the draft lives. It does not state when not to use it or point to diff_game_versions for non-mod diffs.

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 readOnly=true, idempotent=true, destructive=false, and closed-world, so the safety profile is covered. The description adds that the corpus is 'cached mods' and that results carry file:line context, which is useful. It does not disclose how results are grouped (per_mod), pagination, or result ordering.

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 compact sentence with front-loaded purpose and illustrative examples; every clause earns its place. It is terse rather than padded, though the examples trade a little length for clarity.

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 four parameters at 0% schema coverage and no output schema, the description should at minimum explain limit, context, and per_mod. It covers only api_name, leaving an agent unable to tune the query or predict result shape.

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%, so the description carries the full burden, yet it only illustrates the api_name format. The three shaping parameters — limit, context, per_mod — are never explained; 'file:line context' faintly gestures at 'context' but gives no units or semantics.

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: finding real usages of an API name across cached mods with file:line context. The examples of qualified names ('f_addCircle', 'landscape.zones.f_addCircle') make the target concrete. It does not explicitly name siblings like search_api or search_mod_code, so the boundary between this and those tools is left to inference.

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 — you use this to see how an API is actually called in existing mods — but there is no explicit when-to-use guidance and no mention of when to prefer search_api or search_mod_code instead. An agent can infer the context but is not routed.

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/idempotentHint/closed-world, so the safety profile is covered. The description adds the useful fact that key_search runs as a regex over keys and string values, but says nothing about result truncation (max_chars), result size (limit), or behavior when the path is invalid.

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 compact sentences, front-loaded with the resource and then the two useful usage hints. No wasted filler, though the file-category parenthetical is a somewhat noisy enumeration.

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 exists, so return shape is unaddressed, and with five parameters and the required `file` unexplained, an agent cannot reliably know which file strings are valid or how limit/max_chars shape the response. Adequate for the path/key_search workflow but incomplete for full 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 0%, so the description carries the burden and it does explain `path` syntax and `key_search` semantics with examples. However `file` values, `limit`, and `max_chars` (truncation behavior) are left entirely undocumented, so it only compensates for two of five 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 (Query) and resource (Cache/Projects/WarSelection JSON), and enumerates the JSON file categories (gameplay, visual, main, render, interfaces/...), which distinguishes it from siblings like search_api and search_guide. The only gap is that the wording 'Query ... JSON' is slightly loose about whether it reads or writes.

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 concrete usage syntax for `path` ('build[10].costBuilding', 'auras.0') and `key_search`, which is real guidance on how to call it. It never states when to prefer this over the sibling search tools (search_api, unit_lookup, game_info), so the when-to-use comparison is left to 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is carried by structured data. The description complements this by disclosing what content is reported (paths, version, mod count, draft folder, log presence), which is useful given there is no output schema, but it adds nothing about scope, cost, or freshness of the 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?

A single compact sentence with no filler, and the most important item (game paths) is front-loaded. It reads as a fragment rather than a statement of purpose, which slightly hurts scannability from a tool-selection standpoint.

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 zero parameters and no output schema, the description carries the full burden of telling the agent what comes back, and it does list the returned fields. It remains under-specified for ambiguous items ('draft folder and log presence', the WS_GAME_DIR token) and omits usage context, so it is adequate rather than 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?

The tool takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly avoids inventing arguments and instead uses the space to describe outputs.

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 enumerates the environment facts the tool surfaces (game paths, engine version, cached mod count, draft folder, log presence), which goes beyond merely restating the name. However, it is a noun-phrase field list with no verb framing and no differentiation from adjacent tools such as snapshot_game, diff_game_versions, or list_mods, leaving the agent to infer that this is a read-only environment inspection call.

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 rather than a sibling, no prerequisites, and no exclusion conditions. An agent must guess whether it needs a workspace/project context or whether snapshot_game overlaps. Nothing in the text routes the caller.

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 the safe, idempotent, read-only profile, so the bar is lower, and the description adds real context beyond them: the version default (latest) and the 'auto' resolution order (draft in modsStorage/draft if present, else published cache). It does not disclose output truncation implied by max_chars, but the resolution-order detail is genuine behavioral value.

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 front-loaded with the resource and then lists parameter facts in semicolon-separated clauses with essentially zero filler. The telegraphic, fragment-heavy style is efficient, though it occasionally trades clarity for brevity.

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 5-parameter tool with 0% schema coverage and no output schema, the description covers most parameter semantics but omits max_chars and never characterizes the returned source (format/size). With no output schema present, that omission leaves a real gap an agent would want closed.

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 must carry the load, and it does for four of five parameters: mod_id accepted formats ('mod-...' or bare id), version defaulting to latest, kind values ('lua'/'prm'), and source values with their semantics. Only max_chars (default 60000, implying truncation) is left entirely undocumented.

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 'Source of a mod' states the resource returned but is a noun fragment with no explicit verb, and it does not distinguish this tool from siblings like search_mod_code, diff_mod, or lint_mod that also touch mod content. An agent can infer it fetches source, but the purpose is only vaguely bounded relative to the tool family.

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 explicit statement of when to call this tool versus alternatives, nor any prerequisites or exclusions. The explanation of the 'source' values ('auto'/'draft'/'cache') describes a parameter's behavior rather than when this tool should be chosen 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?

Annotations only give the safety profile (writes, idempotent, not destructive); the description adds substantial context beyond them: writes go only to the per-user data folder and never the game folder, dumps of different subtrees are merged, a new engine version replaces the old index with a backup kept, and dry_run writes nothing. This is exactly the extra behavioral detail an agent needs for a mutating import.

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 core action is front-loaded in the first sentence and subsequent sentences each add a distinct behavioral fact. The opening sentence is dense with several parenthetical clauses, but nothing is padded and every clause carries information.

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 complex 8-parameter mutating tool with no output schema, the description covers source selection, the diff report contents (added/removed/changed paths, unexplored subtrees), write targets, and partial-dump handling. It is largely complete, with the remaining gap being the four undocumented parameters.

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 must carry parameter meaning, and it only explains which (log_prev.txt), file (explicit file), dry_run, and allow_partial. The other four parameters (limit, reset, space, dump_id) are left entirely undocumented in both schema and description, so compensation is only 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 specific verbs and resources: parses WSDUMP lines, builds the live API index, and reports a diff against the bundled WSUS index. This distinguishes it clearly from siblings like api_index_status (status only) and api_dump_script (script generation), so an agent can tell them apart without opening schemas.

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 operational conditions: which source to use (gen/log.txt, which='log_prev.txt', or explicit file), that dry_run=true writes nothing, and that a dump without END is refused unless allow_partial=true. It stops short of naming when to prefer this over siblings like api_index_status or api_dump_script, so no explicit alternatives/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?

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds real substance by listing the specific pitfalls detected and noting that unknown f_* names come with suggestions. It omits return format and any limits on code size or mod cache.

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 input modes; the parenthetical pitfall list is dense but each item is informative rather than filler. Slightly run-on, but no wasted sentences.

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 5-parameter tool with 0% schema coverage and no output schema, the description covers input selection well enough to call it correctly. It leaves the `version` parameter and the shape of the diagnostic results unexplained, which is a modest gap.

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% and the schema has no enums, so the description carries the burden: it explains the code/mod_id alternatives, the kind values (auto|gameplay|visual) and the source values (auto|draft|cache). Only `version` is left undocumented.

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 ('Static check of mod Lua code') and then enumerates exactly what is checked (Lua 5.4 syntax plus War Selection pitfalls). An agent can immediately distinguish this from siblings like search_mod_code, diff_mod, or mod_impact.

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 invocation routing ('pass `code`, or `mod_id` of a cached mod') and the meaning of kind/source, which implies the use case, but never states when to reach for this tool versus alternatives such as mod_impact or read_log, nor any prerequisites.

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, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description usefully adds that only cached mods at their latest versions are counted and that results are aggregated with totals per event. It says nothing about ordering, result size, or what happens with an unknown event name.

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, front-loaded with the core purpose, with the parameter note second. No filler and nothing restated from the title or 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 one-optional-parameter read tool with no output schema, the description covers what is measured, what is aggregated, and what the filter does — enough to call it correctly. Return-shape details (field names, ordering, pagination) are absent but minor.

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% and the single parameter has no schema description, but the description compensates by naming the filter and giving a concrete example value ('onUnitInZone'). It does not say whether matching is exact or partial, or whether the name is case-sensitive, so matching semantics remain ambiguous.

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: it reports which addMod events each cached mod registers, with per-event totals. The scope ('cached mods', 'latest versions') is clear enough to distinguish it from list_mods, 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?

Usage is only implied — an agent can infer you call this to audit event registrations, and the optional `event` filter hints at narrowing by one event. There is no statement of when to prefer this over siblings like list_mods or search_mod_code, 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?

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description contributes useful structural context by distinguishing two data sources (modsStorage cache vs modsStorage/draft with a `draft` field), but says nothing about pagination, limits, or developer-mode prerequisites beyond the passing adjective.

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 that leads with the core action and packs in the return structure and filter semantics without filler. Dense but every clause carries information.

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?

An output schema exists, so return-value detail is not strictly required, yet the description still sketches the shape of both result groups. Combined with the filter semantics, an agent has enough to call the tool correctly; only ordering/limits are unaddressed.

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% and the lone `query` parameter is undocumented in the schema, so the description carries the burden. It does that reasonably well by stating the filter is optional and matches a substring on id, which is meaning the schema alone does not convey.

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 (List) and resource (mods), and goes further by enumerating what is listed: published cache entries plus developer-mode drafts. This is more specific than a bare 'list mods', though it never names nearest siblings like get_mod or search_mod_code to sharpen the boundary.

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: enumerate mods, optionally narrow by id substring. There is no explicit when-to-use guidance versus get_mod (single mod) or the search_* tools, and no stated exclusions. The filter note is the only operational context provided.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavioral context: the exact error block patterns it recognizes, that repeats are grouped, and that mods are matched via cached chunk preview plus which mods were active at that time.

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, front-loaded with the core action before edge details. The parenthetical pattern examples are worth their space, though the second sentence is somewhat compressed.

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 non-trivial parsing tool with four undocumented parameters and no output schema, the description should explain the return shape (what a grouped error entry contains) and clarify `limit`/`which`. It describes the analysis behavior well but leaves these gaps for an agent to guess.

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 full burden. It explains `tail` (last N log lines) and gives a concrete format for `since`, which is genuinely useful, but leaves `limit` and especially `which` (the log file selector in a tool hard-coding gen/log.txt) entirely undocumented.

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 (Parse) and resource (Lua errors in gen/log.txt), plus the two transformations applied (group repeats, map to cached mods). This clearly distinguishes it from siblings like read_log and log_tail, which merely surface raw log content.

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 diagnosing Lua errors and correlating them to mods, but never states when to prefer it over read_log, log_tail, or the watch_log_* family. No explicit when/when-not or alternative routing is 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 already cover read-only, idempotent, non-destructive, closed-world. The description adds real behavioral context beyond that: rotation detection (rotated=true) at game start and draining the prior session from log_prev.txt first. It doesn't mention rate limits or output formatting, but the added semantics are meaningful.

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, front-loaded with the core purpose, and each sentence adds a distinct piece of information (return contract, default behavior, rotation handling). Dense but free of 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 read-only tailing tool with no output schema, the description covers the cursor lifecycle, default behavior, and the non-obvious rotation/prev-file case. The one gap is `max_lines`, which an agent cannot infer from anywhere.

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 burden. It explains `cursor` (returns lines since it, emits `next_cursor` for the following call) and `initial_lines` (used when no cursor is given), but `max_lines` is never mentioned in either the schema or the description, leaving one of three parameters undocumented.

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 ("Follow gen/log.txt") and describes the cursor-based return contract, so an agent knows it tails a log. It never names or contrasts with close siblings like read_log or watch_log_start, so differentiation is left to inference.

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 internal usage rules: pass `cursor` to continue, omit it to get the last `initial_lines`. However it never says when to choose this over read_log, log_errors, or the watch_log_* polling siblings, so the usage context against alternatives is only implied.

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, idempotentHint, destructiveHint=false and a closed world, so safety is covered. The description adds genuine context beyond that: the scan target (cached mods and drafts), the categories of changes detected, and the return shape (file:line plus the code line and the reason).

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 sentence with the analytical scope in front and the return format trailing. The enumeration of change categories is long but each item carries information, so there is little 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?

There is no output schema, and the description does cover the return shape and detection categories, which is helpful. However, for a tool whose primary inputs are two snapshots, the complete silence on how to supply or identify a and b (and on limit) leaves a material gap.

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% and none of the four parameters are described. The text implies 'a' and 'b' are the two snapshots being compared and loosely ties 'include_drafts' to the draft scan, but 'limit' is never mentioned and the expected format/identity of a and b is left unstated.

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 specific analytical verb and resource: identifying which cached mods and drafts reference changes between two snapshots, and it enumerates the change categories (unitType ids, build rules, researches, API functions/fields). It is clearly distinct from read-only lookups like get_mod or list_mods, though it never names the closest siblings (diff_game_versions, diff_mod) 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?

No when-to-use guidance is given. It does not say whether the two snapshots must be produced by snapshot_game, nor how this differs from diff_game_versions or diff_mod, so an agent must infer the workflow entirely.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond them: multi-location search, explicit reporting when the log is missing, and the WS_LOG_PATH override. It does not, however, describe return shape or how tail/grep interact, so a 3 rather than a 4.

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 dense sentences with the core action and default path front-loaded. '...' and 'searched in likely locations' are slightly vague, but there is no wasted 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-output-schema, read-only tool of this complexity, the description covers the essentials plus failure behavior. The unresolved overlap with the log_tail sibling and the unexplained tail parameter keep it from being fully 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%, so the description must carry parameter meaning. It maps 'optional regex filter' to grep and the file candidates to which, but never explains tail (how many lines, direction, default 200). It compensates for two of three parameters, leaving one undocumented in both schema and 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?

States a specific verb+resource: it tails a game log, names candidate files (gen/log.txt, log_prev.txt, lagDiagnostics.log) and the optional regex filter. An agent immediately knows what it does, but the description never distinguishes it from the sibling log_tail, which appears to do something very similar.

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 or when-not-to-use guidance, and no alternatives are named despite a near-identical sibling (log_tail) and a related log_errors tool. The mention of WS_LOG_PATH and default locations is environmental context, not usage 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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description reinforces this with '(returned, never written)' and discloses the no-template listing behavior, but adds nothing about output shape or the params argument. Useful but not rich given 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 tight sentences: the core purpose leads, the discovery/listing instruction follows. Template names are enumerated compactly 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?

An output schema exists, so return values need no explanation, and the description covers the list-vs-generate mode and read-only behavior. The only real gap is the unexplained `params` argument for a tool whose schema offers zero parameter documentation.

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%, so the description must carry the burden. It fully explains `template` by enumerating all six valid values and the omit-to-list semantics, but the `params` object remains entirely undocumented in both schema and description. Partial compensation 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?

States a concrete verb+resource: generates starter mod code from guide recipes drawn from working mods. The parenthetical '(returned, never written)' sharply distinguishes it from file-writing or mutation siblings like write_draft. It stops short of naming which sibling to prefer for related lookups.

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 conditional: 'Call without `template` to list templates', which turns the tool into a discoverable list-or-generate flow. It enumerates the valid template values, so the agent knows exactly what it can request. It does not say when to reach for this over find_examples or search_guide.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them: it explains that a live dump takes precedence over a bundled/versioned fallback index and that the `index` result field reveals which source is active, which matters for interpreting results.

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 ('Search the API index'), then supporting detail. Mostly earns its space, though the parenthetical version string ('v258.4018') and cheatsheet reference are closer to trivia than actionable guidance.

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 exists, so the description reasonably covers the important return detail (the `index` field) and the enumerable parameter. Safety is handled by annotations. Gaps around query syntax and limit behavior keep it from being fully complete for a 3-param search 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 0%, so the description must compensate. It usefully enumerates the `kind` values ('function', 'event', 'field', 'note'), which the schema lacks as an enum. However, it leaves `query` syntax and the meaning effect of `limit` (default 20) 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?

States a specific verb and resource ('Search the API index') and describes the two data sources it draws from, which separates it from siblings like search_mod_code, search_guide, and game_data_query. It stops short of explicitly naming an alternative, but the resource is distinctive enough for an agent to route correctly.

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 (search the API index) and explains the data-source mechanics, but never states when to reach for this over game_data_query, find_examples, or list_events_usage. No explicit when/when-not guidance or alternatives are 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the return format (section, line, snippet), which is genuinely useful, but says nothing about matching behavior, result ordering, or how limit truncates results.

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 that front-loads the resource and scoping detail, then states the return shape. No filler or 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 simple read-only two-parameter search with annotations covering safety, purpose plus return fields is close to sufficient. However, the omission of query syntax and limit semantics leaves a real gap for a search tool, even if a minor one.

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%, so the description must carry the parameter burden and does not. It never defines what 'query' accepts (plain text, regex, phrase?) or what 'limit' (default 8) controls or counts. Both params are left to guesswork.

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 (search) and a precisely scoped resource (the bundled Russian modding guide, guide-ru.md), and names the return shape (section, line, snippet). This clearly separates it from sibling searchers like search_mod_code, search_api, and find_examples, which target different corpora.

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 narrow 'bundled Russian modding guide' scope implies when to reach for this over the other search_* tools, but the description never states it explicitly and offers no when-not guidance. Usage is inferable 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: matching is case-insensitive, scope covers both cached code and drafts, and output is file:line with surrounding context lines. It omits what 'cached' implies about staleness, which would have been useful.

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 tight sentence with the operation and payload front-loaded and zero filler. Nothing could be removed without losing information.

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?

Adequate but incomplete for a 5-parameter, zero-coverage search tool with no output schema. It covers the search semantics and return shape, but leaves the limit/latest_only semantics and the freshness of the 'cached' corpus unexplained.

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%, so the description must carry the parameter burden and it only partially does. It hints at the drafts scope (include_drafts) and context lines (context) but says nothing about limit or the meaning of latest_only, leaving two of five parameters undocumented anywhere.

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 concrete verb+resource: regex search over 'cached mod code and drafts', and adds the result shape (file:line with context). This distinguishes it from search_api and search_guide by scope, though it never names those siblings explicitly, so the differentiation must be inferred from the resource noun.

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, when-not-to-use, or alternative guidance is given. An agent must infer from the resource scope that this searches mod source rather than game/API docs; nothing states when to reach for this versus search_api or search_guide.

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 cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds real value on top: the write target is the user data folder and explicitly 'never the game folder', the no-op skip condition mirrors idempotency, and the automatic-on-server-start behavior is disclosed. It does not describe failure modes or what a snapshot looks like, so it is not exhaustive.

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 action and target location, then qualifies with the skip condition and automatic trigger. The long enumeration of captured files is dense but is the actual scope of the operation, so it earns its space; only mild tightening is possible.

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-parameter mutation with no output schema, the description covers where data goes, what is captured, when it is skipped, and when it fires automatically. The only notable gap is the meaning of the label parameter and any notion of the returned result, both of which matter little given annotations already signal a non-destructive idempotent write.

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%, so the description must carry parameter meaning. It does explain force ('Skipped ... unless force=true'), but the label parameter is never mentioned, leaving one of two parameters undocumented in both the schema and the 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?

States a specific verb and resource ('Store a snapshot of the game state') and then enumerates exactly what the snapshot captures (hashes of Cache/Projects/WarSelection JSON, engine-version.txt, normalized content of gameplay.json, visual.json, etc.). No sibling tool does anything similar, so it is trivially distinguishable from the search/query/diff 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 clear operational context: it is skipped when nothing changed unless force=true, and it is taken automatically on server start. That tells the agent when the tool is redundant, but it never states when an agent should call it explicitly or what problem a manual snapshot solves, so it stops short of full when/when-not 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by naming the backing files and stating what comes back alongside each unit ('build rules from gameplay.json (cost, health)'), making the closed-world, read-only lookup concrete. It omits match/limit behavior, which keeps it from a 5.

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 compact sentences with the matching rule front-loaded and examples at the end. No filler; every clause contributes either the lookup key semantics or the returned data.

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 usefully previews the returned fields (cost, health) and the data sources. It does not explain the 'limit' parameter's effect or whether multiple units can match, which are the only material gaps for a two-parameter lookup 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 0%, so the description must carry the load. It does explain the 'query' parameter well (legacy id or asset path substring, with examples), but the 'limit' parameter (default 20) is never mentioned, leaving its pagination/truncation semantics undocumented.

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 ('Find'), resource ('unit types'), and matching semantics ('by legacy id or asset path substring'), plus the concrete data sources (legacyIds.json, gameplay.json). This clearly separates it from generic search siblings like search_mod_code or game_data_query, which don't take a unit identifier/path 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?

The examples ('worker', '201', 'airplane') imply the expected query shape, but there is no explicit statement of when to choose this over overlapping siblings such as game_data_query or game_info, and no exclusions. Usage is implied rather than prescribed.

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 readOnly/idempotent/non-destructive, so safety is covered. The description adds real context beyond them: it discloses the cursor-based polling model and the full shape of each returned event (seq, kind taxonomy, time, script, message, frames, source with mod/draft-cache/file/line/excerpt). With no output schema, this return-value disclosure is valuable, though it omits trimming/pagination 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 dense, front-loaded sentences with no filler; the core semantics (what is returned and the cursor contract) come first. The event-field list is long but earns its place since no output schema exists.

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-parameter polling tool with no output schema, the description covers the cursor contract and event payload reasonably well. It falls short on limit semantics and on any statement of polling behavior (blocking, empty-result handling), which an agent calling this in a loop would want.

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 must carry the burden. It explains since_seq ('new watcher events after since_seq', feeding next_seq forward), which is the critical parameter. But limit is never mentioned, leaving one of two parameters undocumented in both schema and 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?

States a specific verb and resource: returns new watcher events after a cursor sequence. It clearly differentiates itself from watch_log_start/stop by being the read/poll side, though it doesn't name siblings explicitly. The event-kind enumeration reinforces what kind of output to expect.

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 parenthetical 'use next_seq from the previous call' is genuine usage guidance for continuing a polling loop. However, it gives no guidance on when to use this versus log_tail, read_log, or log_errors, and no mention of how limit interacts with polling.

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 readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real behavioral color: it survives log recreation at game start, maps events back to draft or cached mod source, and emits code excerpts. It does not clarify what happens if it is called while a watcher is already running, which matters given the idempotentHint claim on an inherently stateful action.

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 critical information (target file, start point, output routing) is front-loaded, and the closing pointer to watch_log_poll is well placed. The middle clause stacking parse behavior, source mapping, and log-recreation survival is dense, but each clause carries distinct information.

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 the work of explaining what the watcher yields and where to retrieve it, which is the key thing an agent needs. It is slightly incomplete on lifecycle edges — double-start behavior and the relationship to watch_log_stop — but is otherwise self-sufficient 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 0%, so the description must carry both parameters. It documents from_start well (inclusive of the semantic effect of the flag), but the 'warnings' toggle is only obliquely implied by 'engine warnings' — an agent cannot tell from the text what warnings=false suppresses.

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 — 'Start a background watcher on gen/log.txt' — and immediately characterizes the payload it produces (parsed Lua errors, engine warnings, mapped mod source with excerpts). It is clearly distinguishable from read-only siblings like read_log and log_tail, and it names watch_log_poll as the consumer.

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 clear operational context: start the watcher, then 'Read events with watch_log_poll', and it explains the from_start choice as a usage decision (tail from current end vs. replay from the beginning). It stops short of explicit when-not guidance (e.g. when to prefer read_log/log_tail over a live watcher, or when watch_log_stop is required).

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 readOnly/idempotent/non-destructive, so the bar is lower, but the description still adds a genuinely useful behavioral fact: collected events persist and remain reachable via watch_log_poll. That tells the agent stopping is lossless, which the annotations do not 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?

Two short sentences, zero filler, with the action stated first and the retention caveat second. Every clause 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 control tool with rich annotations, coverage is nearly complete: what it does, that data persists, and where to get it. Only the not-running/no-op edge case is left to the idempotentHint annotation rather than stated outright.

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 for the description to disambiguate; the baseline for a no-param tool is 4.

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?

"Stop the background log watcher" is a specific verb+resource, and the second sentence names the sibling (watch_log_poll) that receives the retained output, which cleanly separates this from watch_log_start. An agent can identify the operation without opening the 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?

The usage context is implied (stop the active watcher) and the description routes to watch_log_poll for retrieval, but it never states when stopping is appropriate or whether it is safe to call with no watcher running. No explicit when-not or prerequisites are 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 declare write/not-read-only/not-idempotent but say nothing about scope or recoverability, and the description fills exactly that gap: it discloses the exact target path, that the previous content is backed up to the user data folder (draft-backups), that it never creates files, and that it never touches published files. This is rich, non-obvious behavioral context beyond the 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?

Front-loaded with a 'WRITE:' prefix and organized into purpose, precondition, constraints, and backup behavior. Every sentence carries information, though the file-path syntax is dense and could be parsed more easily.

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 mutation tool with no output schema, the description covers the target file, overwrite semantics, backup destination, and scope exclusions, and reminds the user to 'Save/apply in the game'. Return-value behavior is unaddressed but partially implied by the save/apply note.

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%, so the description must carry the load. It explains the filename pattern that maps to mod_id/version and clarifies that version defaults to the latest draft and that the file uses the .lua extension; only the 'code' content parameter is left implicit. Good compensation for a low-coverage 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?

States a concrete verb ('WRITE: overwrite') and exact resource ('the existing draft modsStorage/draft/<id>_<version>-<hash>.lua'), distinguishing it from siblings by declaring what it will NOT do: 'never creates files and never touches published files'. An agent can tell this apart from scaffold_mod or other writers without opening a schema.

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

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

Gives the precondition for use ('The game creates that file when the mod script is opened with edit script in developer mode') and the default behavior ('latest draft version by default'), which clarifies the context in which the tool applies. It does not name an explicit alternative or when-not-to-use case, 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.