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

Annotations already declare readOnlyHint=false and openWorldHint=false, so the agent knows this is a local mutation. The description usefully adds that the name is validated against the catalogue, but omits duplicate handling, idempotency, and any favorites limit.

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

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

A single well-formed sentence with the action front-loaded and no wasted words; the validation caveat is placed inline where it matters.

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, no-output-schema mutation tool with annotations covering safety, the definition covers what to add and to where. Only edge-case behavior (duplicates, capacity) is missing, which is a minor 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 description coverage is 100%, so both parameters are already documented in the schema. The description adds only the catalogue-validation constraint on 'name', which is a modest value-add 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 ('Add') and resource ('radial-wheel favorites'), plus the accepted entity types (dance or moveset). It is distinguishable from siblings like reanim_remove_favorite and reanim_list_favorites, though it does not explicitly name 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?

Usage is implied by the name and description but there is no explicit when-to-use guidance, no mention of the alternative reanim_remove_favorite or reanim_list_favorites, and no stated prerequisites beyond catalogue validity.

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=false and openWorldHint=false, so the agent knows this is a closed-world mutation. The description adds real value by naming the mutated field (SaveData.Custom) and stating that a live snippet is returned despite there being no output schema, but it never says whether an existing customization is overwritten or how to undo the change.

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 with the verb and target front-loaded and no filler. It is appropriately sized, though 'live snippet' is unexplained jargon that slightly blunts the payoff of an otherwise tight sentence.

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 essentials (what it writes to, that it returns a snippet) and annotations cover the safety profile. It nevertheless omits whether existing theme state is replaced, whether a prior list call is required, and what the returned snippet is for.

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

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

Schema coverage is 100% and the single required parameter is already documented in the schema, including its provenance ('Preset name from reanim_list_theme_presets'). The description's phrase 'built-in theme preset' only mildly reinforces that constraint, so the 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 (apply) plus resource (built-in theme preset) and names the exact mutation target (SaveData.Custom), which separates it from read-side siblings like reanim_list_theme_presets and reanim_get_ui_theme. It doesn't explicitly contrast with the nearby write tools reanim_set_ui_theme or reanim_set_customization, so an agent still has to infer which write path applies.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternatives. The only routing hint ('Preset name from reanim_list_theme_presets') lives in the schema, not the description, and there is no mention of how this differs from reanim_set_customization or reanim_set_ui_theme.

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=false and openWorldHint=false, so the write/local nature is already covered; the description usefully adds that backups are timestamped and land in a specific directory, implying non-destructive accumulation rather than overwrite. It does not say whether the destination folder is created if missing, whether the copy is atomic, or what happens on failure.

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 with the source, destination and naming scheme front-loaded and no filler. Nothing can 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?

For a zero-parameter backup tool with annotations covering the safety profile, the description covers the essential mechanics. It omits the return value (there is no output schema), specifically whether the generated backup path/timestamp is reported so the agent can later pass it to restore_savedata.

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 schema coverage is 100%, so there is nothing for the description to document; the baseline of 4 applies. The description correctly implies no input is required since source and destination are fixed.

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 (copy), a concrete source (tree.ehehetilde) and a concrete destination (UhhhhhhReanim/Backups/) plus the timestamping behavior, which goes beyond the title 'Backup SaveData'. It does not, however, reference the inverse sibling reanim_restore_savedata, so an agent must infer the pairing from the name alone.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as reanim_restore_savedata or reanim_get_savedata. The agent is left to infer that this is the pre-modification snapshot operation.

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 establish this as a non-destructive local read (readOnlyHint=true, openWorldHint=false), so the safety profile is covered. The description adds real behavioral value by naming the four check categories the tool performs, which tells the agent what the diagnostic actually examines.

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 with the verb and resource first, followed by a compact enumeration of checks. Zero filler and nothing redundant with the title.

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 and no output schema, the description carries the return-value burden, and the enumerated check categories largely cover what the report contains. It stops short of describing the result format (pass/fail, list of issues, severity), which would fully close the 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. It correctly avoids inventing filter options that do 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 (Validate) and resource (dance catalogue) and enumerates exactly what it inspects: counts per file, packed MARKET entries, duplicate names, keybind coverage. The dance scope distinguishes it from reanim_check_movesets, though it does not name that sibling directly.

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 says what it validates but never states when to run it, what precedes it, or how it relates to alternatives like reanim_check_movesets, reanim_validate_module, or reanim_doctor. No exclusions or preconditions are 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile needs no restating. The description adds genuine behavioral detail beyond that: it inspects m.Assets entries specifically, distinguishes present files from missing ones, and notes that expected paths are surfaced in the report — a useful disclosure of output shape for a diagnostic tool.

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 operation front-loaded and zero filler; every clause (parse targets, existence split, expected paths) contributes information. Nothing could be removed 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?

With no output schema, the description correctly compensates by describing the report contents (present vs missing files, with expected paths). Single fully documented parameter plus read-only annotations means little else is needed; only error/edge-case behavior for an unresolvable target is 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 description coverage is 100% for the single 'target' parameter, so the schema already carries its meaning; the baseline of 3 applies. The description only tangentially narrows the target to a module's asset table and adds no format examples or fallback behavior for an invalid module name.

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 specific verbs (parse, report) with a precise resource (a module's m.Assets entries) and even names the asset types and directory (.anim/.mp3 under Content/), so the operation is unambiguous. It stops short of the top mark because it never differentiates itself from adjacent diagnostics such as reanim_validate_module, reanim_check_movesets, or reanim_check_dances.

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

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

There is no when-to-use guidance at all: no prerequisite (e.g., run after reanim_list_modules or before enabling a module), no statement of when this check matters versus validate_module, and no exclusions. The only guidance is what the tool does, leaving the agent to infer its role.

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 and openWorldHint=false, so safety is covered. The description adds useful behavioral substance by naming the exact diagnostic categories produced, but doesn't state output format, severity levels, or whether it repairs anything (it does not).

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 a colon-delimited checklist. Every clause carries information and nothing is padded.

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 parameters, the description's enumeration of validated categories effectively serves as the return summary. It is close to complete; only the shape/severity of the reported results is omitted.

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

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

The tool takes zero parameters, so the baseline is 4. There is no parameter surface for the description to enrich, and it correctly spends no words on inputs.

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 ('Validate') and resource ('moveset catalogue') and enumerates exactly what is checked: counts per file, missing Name/Type, MovesetIndex range, ContentHash coverage. This is far more specific than a tautology, though it doesn't explicitly contrast itself with nearest siblings like reanim_check_dances or reanim_validate_module.

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 tool name and read-only validation framing, but the description never says when to run it (before export, after edits, on failure) or what to do with results. No alternative or prerequisite is named.

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 that this is a write operation (readOnlyHint=false, openWorldHint=false). The description adds meaningful behavioral context beyond that: the tool scaffolds from a template into a specific directory and the created module will not load until modules are reloaded or reanim.luau is re-run. It does not disclose overwrite/failure behavior for pre-existing files.

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 plus a short clause, front-loaded with the core action and destination, then prerequisites, then the post-creation step. Every sentence earns its place with no filler.

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

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

For an 8-parameter write tool with no output schema and full schema coverage, the description covers the action, artifact location, key input constraint, and the required follow-up load step. It omits nothing critical, though it could note the default no-overwrite behavior, which is left 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 coverage is 100%, so the baseline is 3. The description adds constraint semantics the schema lacks — that anim must reference an *existing* Content/Anims name (not an arbitrary filename) and that song is an optional .mp3 — clarifying the expected value domain beyond the schema's example format.

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 (scaffold/create), the exact artifact (a DANCE user module .lua), and its destination (UhhhhhhReanim/Modules/) sourced from a template. This distinguishes it cleanly from the sibling reanim_create_moveset, which produces a different artifact type.

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 real prerequisites — anim must be an existing Content/Anims name or a 'file@url' — plus a follow-up step (reload modules), which is implied usage context. However, it never states when to choose this over reanim_create_moveset or the other dance tools, and gives 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 readOnlyHint=false and openWorldHint=false, so the write/local nature is known. The description adds genuine context beyond that: the created artifact is a blank .lua placed in a specific folder, and it only takes effect after a reload — a side effect/state requirement not covered by 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?

Three short, front-loaded sentences: purpose first, then next-step and load instructions. Each sentence carries actionable information with no filler, though the middle "Edit Update() to animate" is light tutorial guidance rather than definitional content.

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

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

For a file-creating tool with no output schema, the description covers where the file lands, that it is blank, and how to activate it. It omits return value and whether overwriting is destructive beyond the schema's overwrite flag, but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 100%, so all four parameters (file, name, overwrite, description) are already documented in the schema. The description adds only "blank" as content context and does not clarify parameter behavior beyond the schema, so baseline 3 applies.

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

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

States a specific verb ("Scaffold"), a precise resource ("MOVESET user module (.lua)"), and the target directory (UhhhhhhReanim/Modules/). The MOVESET qualifier cleanly separates it from the dance-module creation sibling (reanim_create_dance).

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

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

The description gives post-creation workflow (edit Update(), reload modules / re-run reanim.luau), which is useful, but never states when to choose this over siblings like reanim_create_dance or how it relates to reanim_generate_snippet. Usage is implied rather than explicit.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=false, so the description carries the rest and does so well: it explains the file is renamed rather than deleted, and that the change only applies on the next run. Those are exactly the behavioral traits an agent needs and they are not derivable from 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 short sentences, zero filler, with the core action and the safety qualifier front-loaded before the deployment caveat.

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 mutation tool with no output schema, the description covers what changes on disk and when it takes effect. Minor gaps remain, such as behavior when the named plugin is not currently active or whether the file must exist, but nothing essential is missing.

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

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

Schema coverage is 100% and the single 'file' parameter already has a description and example ('VoidAnchor.lua'). The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource ('Disable an active plugin') and even names the mechanism used ('.lua -> .lua.txt'). The counterpart sibling reanim_enable_root_plugin is only implied rather than named, so it falls just short of full sibling differentiation.

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 useful operational context ('without deleting it', 'Takes effect on re-run'), which implies the non-destructive alternative to a removal tool. However, it never states when to prefer this over reanim_remove_module or how it relates to reanim_enable_root_plugin, so guidance remains 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds real value beyond them by scoping the breadth of inspection and disclosing the return shape ('issues list and ok flag'), which matters since there is no output schema.

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 front-loads the operation and the return values are appended efficiently. The clause list is long but each item describes a distinct check, so little 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 read-only annotations, this description covers what an agent needs: what it validates and what it returns. Only the absence of explicit routing advice against sibling checkers keeps it short of 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 the baseline is 4; there are no arguments whose semantics could be ambiguous or under-documented.

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 operation ('Full health check') and enumerates exactly what is inspected: script/bridge version, SaveData validity, moveset index range, counts, duplicates, builtin hashes, folders. This clearly separates it from narrower siblings like reanim_check_movesets and reanim_check_dances, though it never names those alternatives 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: the 'Doctor' framing and 'Full health check' make it obvious this is the run-when-something-seems-wrong tool, distinct from targeted check_* siblings. There is no explicit when-to-use, when-not-to-use, or named alternative.

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?

Goes beyond the readOnlyHint=false annotation by disclosing that the change is a file rename, only takes effect on re-run, and explicitly will not touch README. These are non-obvious behavioral traits, though error/permission behavior is still unstated.

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 fragments with the core action front-loaded and zero filler. The telegraphic style is efficient, if slightly abrupt.

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

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

For a single-parameter mutation tool whose annotations already declare the write/openWorld profile, the description supplies the key mechanic and two important caveats. Nothing essential for invocation is missing.

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

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

Schema coverage is 100% (the file param is fully described with an example), so the schema carries this dimension. The description only reinforces the filename convention via '.lua.txt -> .lua' and adds no syntax beyond the schema.

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

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

States a specific verb (Enable) and resource (plugin), and explains the concrete mechanism as a file rename (.lua.txt -> .lua). This clearly contrasts with the sibling reanim_disable_root_plugin, though the sibling is not named.

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 never says when to use this versus alternatives or the disable counterpart, nor what precondition (a currently disabled plugin) must hold. Usage is only implicit in the verb.

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 and openWorldHint=false, so they don't cover mechanics. The description adds real value by revealing the write target (a file at UhhhhhhReanim/Profiles/<name>.json), but it omits whether an existing file is overwritten, permission requirements, or what the tool returns on completion.

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 verb and the payload, so it's efficient. The garbled path string is the only structural blemish.

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

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

For a single-parameter export with no output schema, the description covers what is exported and where, which is most of what an agent needs. It leaves gaps on result handling and overwrite/conflict behavior that a caller would want before invoking a write tool.

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

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

Schema description coverage is 100% (the single param 'name' is documented as 'Profile name'), so the baseline is 3. The description adds a small amount by showing name is interpolated as the filename (<name>.json), but no format, character, or collision semantics beyond the schema.

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

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

Specific verb (Export) plus the resource (a profile bundle) and it enumerates exactly which settings are included: theme, movement, wheel favorites, audio. It's clearly distinguishable from reanim_import_profile by direction, though it never names the alternative explicitly. The odd 'UhhhhhhReanim' path segment slightly muddies the target.

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. The word 'shareable' hints at intent (sharing/backup), but there is no explicit statement of when an agent should call this versus reanim_import_profile, reanim_backup_savedata, or the list/get tools.

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 and openWorldHint=false, and the description's 'without changing files' reinforces that safety profile rather than contradicting it. It adds the 'executor-ready' framing, but says nothing about the return format, size limits, or whether generated code has side effects when run externally.

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: verb, resource, supported kinds, and the key non-mutating constraint all appear up front. Nothing needs to be trimmed or reordered.

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 generation tool with fully documented schema this is nearly sufficient, and annotations cover the safety profile. The remaining gap is that there is no output schema and the description never states that the result is Luau code text the caller must run itself, which is the one thing an agent would want confirmed.

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% with a documented enum for `kind` and per-parameter descriptions, so the schema already carries the semantics. The description's enumeration of kinds mirrors the enum without adding format, constraints, or interaction rules (e.g., that `custom` only applies to kind=custom) beyond what the schema shows.

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 (build a Luau snippet) and enumerates the supported kinds (dance/moveset/theme/custom action). The phrase 'without changing files' behaviorally distinguishes it from write-oriented siblings like reanim_create_dance or reanim_switch_moveset, though no sibling is named directly.

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 clause 'without changing files' implies the usage context (generate code for external execution instead of applying changes), which is meaningful routing signal. However, it never explicitly says when to choose this over reanim_create_dance, reanim_create_moveset, or the apply/switch tools, leaving the agent to infer.

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 and openWorldHint=false, so the safety profile is covered. The description adds the concrete flag names being read, which is mild useful context, but says nothing about return format, defaults, or whether flags can be absent.

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 names the resource and its contents without preamble or filler. It is efficient; the terseness is a stylistic choice rather than padding.

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

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

With no input parameters and no output schema, the description carries more weight for describing return values. Listing the three flags read is helpful, but it omits the return shape (booleans, JSON object, etc.), leaving a minor but real gap for a getter tool.

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

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

The tool takes zero parameters, so per the baseline there are no parameter semantics to explain and no schema gap to compensate for. The description's enumeration of the three flags is a bonus rather than a requirement.

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 ('Read') and enumerates the exact resource contents (MuteUIMusic / MuteReanimMusic / MuteUISound flags), so the agent knows precisely what state it retrieves. It does not name its obvious counterpart reanim_set_audio, so it falls short of full sibling differentiation.

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 'use when' clause, but the read/set pairing with reanim_set_audio makes the usage implied: read current state before mutating it. No exclusions, prerequisites, or alternatives are 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 cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds genuinely non-obvious behavior: dances are runtime-only and the script persists only MovesetIndex, which warns the agent that the returned value may not survive a session restart. It also discloses a secondary output (keybind paging) that annotations cannot 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 clauses, front-loaded with the primary purpose before the parenthetical caveat and the secondary output. No filler 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?

With no parameters and no output schema, the description carries the return-value burden itself and does so: it names the primary value (last switch_dance pick) and the secondary one (keybind paging), plus the persistence caveat. Nothing an agent needs to interpret the response is missing.

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 of 4 applies. No parameter-level detail is needed.

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

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

States a specific verb and resource: it shows the last dance picked via switch_dance, and additionally reports keybind paging. This is distinguishable from the neighboring reanim_get_current_moveset and reanim_list_dance_keybinds, though the 'current dance' phrasing could be tightened to say it is a state read.

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

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

No explicit when-to-use or when-not-to-use statement and no named alternative is given, but the reference to 'last MCP switch_dance pick' strongly implies this is the read-back companion to reanim_switch_dance. 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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully adds what is aggregated (saved index/hash from tree.ehehetilde, last switch pick, resolved name), which is real context beyond the annotations. It does not describe the response shape or what happens when no moveset is saved, leaving a moderate 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?

A single efficient sentence with no padding. It is front-loaded on the primary output. The internal jargon ('tree.ehehetilde') reduces readability slightly but costs no length.

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 read-only annotations, the burden is light. The description does name the components returned, which is helpful, but the opaque 'tree.ehehetilde' reference and the absence of any note on empty/unsaved state leave it only adequately 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 the baseline is 4. There is nothing for the description to document here, and it does not confuse the picture.

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 (Show) and a specific resource (saved MovesetIndex/MovesetHash, last switch_moveset pick, resolved name). It is a clear 'get current state' tool distinguishable from reanim_switch_moveset by the read-only framing. It does not explicitly distinguish itself from the parallel reanim_get_current_dance or reanim_check_movesets 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?

No guidance on when to use this versus reanim_check_movesets, reanim_list_movesets, or reanim_switch_moveset. The mention of 'last MCP switch_moveset pick' implies a relationship to that sibling but never states the condition for choosing this tool. Usage must be inferred entirely from the name.

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 (readOnlyHint=true, openWorldHint=false), so the description's burden is lighter. It does add one useful behavioral fact beyond the annotations: the returned table has defaults filled in for unset options. It says nothing about size, caching, or whether the read reflects persisted vs in-memory state.

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 return subject and uses the parenthetical only to enumerate fields. Every clause earns its place; the parenthetical list is dense but informative rather than filler.

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

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

With no output schema, the description must carry the return shape, and it does so by naming the table and its option groups plus the defaults-filling behavior. For a zero-arg read this is nearly complete, missing only notes on freshness or how it relates to the setter.

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 (schema coverage 100% on an empty object), so there is nothing for the description to disambiguate; the baseline for a no-parameter 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?

States a specific verb ('Return') and resource (the full SaveData.Custom table), and enumerates the option categories it contains, so an agent knows exactly what comes back. It does not name its write counterpart (set_customization/reset_customization) to sharpen the read-vs-write distinction, but the name and read framing are 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 call this versus set_customization, reset_customization, or get_ui_theme. Usage is only implied by the tool name; nothing tells the agent it should read before mutating or that it is the defaults-filled baseline.

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 and openWorldHint=false, so the safety profile is covered. The description adds return-content detail the annotations cannot supply: the AddModule fields returned plus a size value. It omits error behavior for a missing/unparseable file, but with annotations lowering the bar this is a solid addition.

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 action and return contents, then the argument flexibility. Every clause earns its place with no 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?

There is no output schema, so the description appropriately enumerates the returned AddModule fields and size, making it callable without guesswork. It stops short of describing not-found or malformed-file behavior, a minor gap for a read-only parser.

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?

With 1 parameter at 100% schema coverage the baseline is 3, and the description adds meaning beyond the schema's example: it clarifies the single 'file' argument may be either a bare filename or a full path. No enum or type details are needed beyond that.

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: 'Parse one module file and return its AddModule entries'. The return fields (type/name/description/InternalName) make the output concrete, and 'one module file' signals the single-file scope versus list-oriented siblings. It does not explicitly name a sibling like reanim_list_modules, so it is clear but not fully differentiated.

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?

'Accepts filename or full path' hints at flexible invocation but never states when to use this over reanim_list_modules, reanim_validate_module, or reanim_check_module_assets. Usage is implied by the parse-one-file framing rather than explicitly guided.

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 and openWorldHint=false, so the safe read-only nature is covered. The description adds the specific setting categories that are read, but says nothing about return shape, defaults, or how the flags relate to reanim_set_low_end_mode; with annotations carrying the safety profile a 3 is appropriate.

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 naming the primary setting (LowEnd UI mode) first and the remaining flags after. No padding, though the trailing 'and related perf flags' is slightly vague.

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

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

For a no-parameter, no-output-schema getter with read-only annotations, the description covers what is read and is sufficient to invoke correctly. The absence of any return-shape hint is the only minor 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate beyond confirming it is a bare read.

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 (Read) plus the concrete resource (LowEnd UI mode, FXBlur, FXSounds, FXTransitions, FXAmbient and related perf flags). An agent can tell what it returns, though it does not explicitly contrast itself with near-neighbors like reanim_get_ui_theme or reanim_get_root_settings.

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 indication of when to call this versus the many overlapping getters in the sibling list (reanim_get_ui_theme, reanim_get_customization, reanim_get_root_settings, reanim_set_low_end_mode). Usage is only implied by the tool name.

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 and openWorldHint=false, so safety is covered and the bar is lower. The description's one contribution beyond annotations is enumerating the fields that come back, which is genuinely useful since no output schema exists, but most field names (FlingMethod, ServerReanim, ClickFling, PhysicsRepRootPartFling) are left unexplained.

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 compact sentence with no waste, which is good, but it is a noun-list fragment with no front-loaded verb or purpose statement, so the reader must infer the action and infer what the listed identifiers mean.

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 parameters, the description carries the burden of explaining returns, and it only partially delivers: it names the settings returned but clarifies meaning for just one entry (CharMove) while leaving the others opaque to an agent. For a simple parameterless read this is adequate but clearly incomplete.

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; baseline 4 applies. The parenthetical 'CharMove (Walk/Fly speed)' is a small bonus that hints at the returned value semantics without any input parameter to describe.

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 is a bare comma-separated list of field names (SelectedReanimator, Reanimator, FlingMethod, etc.) rather than a sentence stating the action and resource, so it largely restates the title 'Get reanimator settings'. It does scope what is read, which helps distinguish it from reanim_set_reanimator_settings, but it gives no basis for choosing it over reanim_get_root_settings or reanim_status.

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

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

There is no when-to-use guidance at all: no mention of when this should be called versus reanim_get_root_settings, reanim_status, or reanim_get_customization, and no prerequisites or context such as whether the API must be running. The only implied usage signal is the 'get' verb in the name.

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 and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral detail — the values are returned as human-readable names rather than raw identifiers — but says nothing about return format otherwise, which is acceptable given the lighter bar set by 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?

A single efficient sentence with the operation and the returned data front-loaded. It is well-sized, though the phrasing 'limb RootPart mode / velocity / init selections' is slightly list-dense.

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-argument read-only getter with no output schema, the description conveys what data comes back and in what form (human-readable names), which is largely sufficient. It stops short of describing the shape of the returned object or how it relates to reanim_set_root_mode.

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 a 4 is appropriate; there are no argument semantics to document and the description does not need to compensate.

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 (Read) and a concrete resource (limb RootPart mode / velocity / init selections), which is far more informative than the title alone. It distinguishes itself from the write-side sibling reanim_set_root_mode by using 'Read' versus 'Set', though it does not explicitly name that sibling.

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

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

The description contains no when-to-use or when-not-to-use guidance and never points to reanim_set_root_mode as the counterpart mutator or to other getters. An agent must infer the usage from the verb alone.

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 and openWorldHint=false, so the safety profile is covered. The description adds that output is raw (vs typed) and oriented to debugging, which is useful, but it does not surface the size/perf implications of the optional huge ModuleConfigs payload.

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 clauses, front-loaded with what is returned and followed by usage guidance. Every word earns its place with no 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 trivial one-param read tool with annotations covering safety and no output schema, the description is largely sufficient. It could say a bit more about what the top-level summary contains or the cost of the optional flag, but nothing critical is missing.

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%, and the single includeModuleConfigs param is already documented as including a 'huge ModuleConfigs map'. The description adds no extra meaning about that parameter, so the baseline 3 applies.

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

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

States a specific verb (Return) and resource (raw SaveData keys, with the two sections it contains), and explicitly contrasts with the typed getters siblings. It is easy to distinguish from reanim_get_customization, though 'SaveData keys' remains somewhat abstract without further context.

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 clear use case ('useful for debugging') and names an alternative ('prefer the typed getters for edits'), implicitly steering the agent away from using this for edits. It lacks an explicit when-not or a named sibling tool, so it stops just short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety and scope profile is covered. The description adds the useful fact that the returned surface is the theme-related 'Custom' key set, but says nothing about return shape, defaults, or what happens when a key is unset.

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: verb first, then the enumerated payload. The key list is long but each item is informative rather than padding, though the trailing 'etc.' slightly undercuts the precision the list was building.

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 zero parameters, the enumeration of keys serves as a partial return-value specification, which is above what the structured fields provide. The 'etc.' leaves the exact key set open, but for a simple getter this is close to 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; per the rubric this yields a baseline of 4. The description correctly does not invent any input concepts.

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 ('Read') and resource ('theme-related Custom keys') and enumerates the exact keys returned, which is far more concrete than a restated title would be. It implicitly contrasts with the sibling reanim_set_ui_theme, but never names it, so sibling differentiation is only implied.

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 use this versus alternatives such as reanim_set_ui_theme, reanim_get_customization, or reanim_list_theme_presets. The imperative 'Read' implies a getter, but no conditions or exclusions 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 flag destructiveHint=true, but the description adds real behavioral value beyond them: it discloses that current SaveData is backed up first and that Custom is deep-merged while other keys are replaced. That clarifies exactly what gets overwritten versus preserved. It stops short of covering failure modes or whether the backup is user-visible.

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, and the most consequential fact (auto-backup) is placed up front followed by the merge semantics. 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 single-parameter tool with no output schema, the description covers the important behaviors: backup, merge strategy, and destructive replacement, while annotations cover the safety profile. Minor gaps remain around error handling and where the backup lands, but nothing essential to calling it is missing.

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% with one param, so the schema already explains that 'name' is a profile name or filename in Profiles/. The description adds no further parameter semantics beyond the phrase 'profile JSON', so the baseline 3 applies.

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

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

States a specific verb and resource (import a profile JSON) and adds concrete scope: it auto-backs up SaveData and has differentiated merge behavior (deep merge for Custom, replace for other keys). An agent can distinguish this from reanim_export_profile. It stops just short of explicitly naming the sibling it complements.

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 import a profile versus alternatives like reanim_restore_savedata or reanim_apply_theme_preset, and no stated prerequisites for the profile source. The agent must infer usage from the name alone.

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 and openWorldHint=false, so safety is covered. The description goes further by disclosing concrete return content: the 15 slot/letter mapping and the notion of a 'current page', which reveals pagination behavior an agent would otherwise not know.

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 covering scope and return content with no filler. The parenthetical letter list is verbose but arguably informative for slot layout, so it mostly 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-param read-only tool with no output schema, the description adequately explains what the return contains and even hints at pagination. Complete enough to call correctly, though it doesn't explain how to change pages.

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 no parameters, so per the rubric the baseline is 4. There is no parameter semantics for the description to carry, and schema description coverage is 100%.

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 ('Show') and resource ('dance keybind slots'), and enumerates the return content (slots, current page, MCP-assigned dances), which distinguishes it from the write sibling reanim_set_dance_keybind. It doesn't explicitly name a sibling, but the read verb and scope make the intent 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 – an agent can infer this is the read/view operation for inspecting keybinds, but there is no explicit when-to-use, no mention of the related set_dance_keybind mutation, and no conditions that select this tool over alternatives such as reanim_get_current_dance.

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 this as a safe read. The description adds value by naming the fields it returns (index, name, file, description) and by disclosing the parsed source set including packed MARKET files, but says nothing about ordering, pagination interaction with limit, or how query matching works.

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, front-loaded with the verb and scope, with the return fields trailing. No filler, though the parenthetical scope detail is dense.

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

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

For a simple read-only listing tool with full schema coverage, the description is largely complete: it covers scope and return fields, which matters since there is no output schema. It stops short of explaining ordering or how query filters match, but nothing critical is missing.

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

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

Schema description coverage is 100%, so both limit and query are already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb (List) and resource (dances), and clarifies the scope of what is parsed: builtin v_dance1-2 plus Modules/*.lua including packed MARKET files. It does not explicitly contrast itself with the many sibling list/check tools, but the scope detail makes the target set unambiguous.

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

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

The description never says when to reach for this tool versus reanim_check_dances, reanim_get_current_dance, or the other listing tools. The listing intent is implied by the verb 'List', but there is no explicit when-to-use guidance or exclusion.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful provenance (data lives in SaveData.WheelFavs) but says nothing about return shape, ordering, or what an empty result means.

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 scope (dance/moveset, WheelFavs) comes first and the explanatory gloss trails it. The GTA reference is arguably jargon that could be dropped, but it aids recognition.

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

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

For a no-param, read-only list tool with no output schema, the description conveys what is listed and where it comes from, which is enough to call it correctly. Only minor gaps remain (return format, ordering).

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 per the rubric the baseline is 4. Schema coverage is 100% and there is nothing for the description to disambiguate.

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

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

Specific verb ("Show") plus concrete resource ("SaveData.WheelFavs dance/moveset name lists"), and the parenthetical clarifies the concept as a GTA-style quick wheel. It is distinguishable from add_favorite/remove_favorite by the list/show semantics, though it never names those siblings 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 inspect existing wheel favorites. Nothing states when to prefer it over reanim_get_savedata or the add/remove_favorite pair, and there are no exclusions or 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=true and openWorldHint=false, so the safety profile is covered. The description adds the useful scope detail that it scans seven named directories, but says nothing about return format, filtering, recursion into subfolders, or whether the list is cached/refreshed.

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 action and resource and then supplies the directory constraint. Nothing is padded or redundant.

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 read tool whose annotations cover safety, the definition is adequate, but with no output schema the agent gets no hint about what is returned (filenames, paths, counts) or how it relates to reanim_get_module_info and reanim_check_module_assets.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no filtering arguments are accepted, since the directory scope is fixed internally.

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 (.lua module files) and enumerates the exact directories scanned, which is concrete and identifiable. It does not explicitly distinguish itself from close siblings like reanim_list_root_plugins, but the enumerated directory scope does most of the differentiation work.

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 versus reanim_list_root_plugins, reanim_get_module_info, or reanim_search_features. No prerequisites, no exclusions, no indication of when this listing is the right first step.

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 and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing data provenance (builtin v_moveset1-3 plus Modules/*.lua) and the exact return fields, which matters because no output schema exists.

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 tightly packed sentence: scope first, provenance second, return shape last. No filler and nothing that could be trimmed 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?

For a read-only list tool with no output schema, the description covers source scope and returned fields, which is what an agent needs to interpret results. It omits ordering, result-size, or pagination behavior, a minor gap for a likely small local dataset.

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% and the single 'query' parameter is fully documented in the schema as a case-insensitive filter on name/InternalName/file. The description adds nothing about the filter, so baseline 3 applies.

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

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

States a specific verb+resource ('List all parsed movesets') and narrows scope with provenance details (builtin v_moveset1-3 + Modules/*.lua), which helps distinguish it from reanim_list_dances and reanim_get_current_moveset. It stops short of explicitly naming the sibling it is not, so it lands at 4 rather than 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?

There is no when-to-use guidance, no mention of how it differs from reanim_check_movesets or reanim_get_current_moveset, and no note about when the optional filter should be applied. The purpose implies enumeration, but the agent must infer all routing decisions.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful context by naming the two scanned directories and mentioning sizes, but it omits whether the listing is recursive, ordered, or paginated across folders.

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 states exactly what the tool does, where it looks, and what it returns. 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 low-complexity, single-parameter read tool with no output schema, the description gives enough to invoke it correctly: what is listed, where, and that sizes are included. It could be more explicit about the returned entry structure (e.g., paths vs names), but the gap is 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 description coverage is 100%, so the single 'limit' parameter is fully documented in the schema as 'Max entries per folder'. The description adds no extra meaning beyond what the schema already provides, matching the baseline for high schema coverage.

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 gives a specific verb (List), a precise resource (.mp3 files), and exact scope (Muzik/ and Content/Sounds/), plus a return detail (with sizes). No sibling tool lists music files, so it is unmistakable against reanim_list_dances, reanim_list_movesets, etc.

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 states what is listed but gives no explicit when-to-use guidance, no prerequisites, and no alternatives. The agent must infer that this tool is for inspecting available music files, which is not spelled out.

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 with readOnlyHint=true and openWorldHint=false. The description adds useful content scope by naming RootPart modes, plugin files, and selected mode, but discloses no operational details such as where files are read from or output 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 front-loaded sentence that enumerates the three output categories without filler. 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?

No output schema exists, so the description carries the burden of explaining return content and does so by naming modes, plugin file states, parsed names, and selected mode. It lacks only minor formatting/ordering detail, which is not critical for a zero-parameter read-only list.

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

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

The tool has zero parameters, so parameter semantics baseline is 4. There is no parameter documentation needed or provided.

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 concrete resources (builtin RootPart modes 0-6, active/disabled Plugins/ files, selected mode). The resource scope distinguishes it from generic list tools like reanim_list_modules, though it does not explicitly name an alternative.

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 no when-to-use guidance, no prerequisites, and no alternatives. It only describes returned content, leaving the agent to infer that this is a read-only inspection tool.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral content beyond that: the set is fixed, built-in, and exactly 10 items, so the agent knows the response is small and complete rather than unbounded.

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 count and example names are the only content and both earn their 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 parameterless enumerator with no output schema, the description gives enough to predict the response (a fixed list of preset names). It could note the return shape or how a preset name feeds into reanim_apply_theme_preset, but nothing critical is missing.

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 for the description to disambiguate. Baseline 4 applies; the description correctly avoids inventing filter arguments that do 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 concrete verb ('Show') and a well-scoped resource ('the 10 built-in UI theme presets'), with parenthetical examples that make the content unambiguous. It clearly reads as an enumeration tool, distinct from reanim_apply_theme_preset or reanim_set_ui_theme, though it never names those siblings 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 the discovery step before applying a preset, but the description never says when to call it versus reanim_get_ui_theme or reanim_apply_theme_preset. No prerequisites, sequencing, or exclusions 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=false and openWorldHint=false, so the mutating/local nature is covered. The description adds credibly useful context ('record it', 'return the live-switch snippet') about side effects and output, but does not say what 'record' persists or where. Adds value beyond annotations without fully covering side-effect 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?

A single front-loaded sentence carrying the action, an optional filter, the side effect, and the return value with zero filler. Nothing is wasted or 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?

With no output schema, the description compensates by naming the return value ('live-switch snippet'). For a one-param, annotation-covered tool this is close to complete, though the persistence semantics of 'record' remain 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 100% and the single parameter is already documented as an optional name/file filter. The description's '(optional name filter)' merely restates the schema, adding no syntax or semantics. Baseline 3 is correct when the schema does the work.

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 chain: pick a random dance, record it, and return a live-switch snippet. This distinguishes it from reanim_random_moveset at the resource level and from reanim_switch_dance at the action level. It stops short of differentiating from reanim_surprise_me or reanim_create_dance.

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 '(optional name filter)' implies when the filter applies, but there is no explicit guidance on when to use this over reanim_surprise_me, reanim_random_moveset, or reanim_switch_dance. Usage is only inferable, not 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 only say readOnlyHint=false and openWorldHint=false; the description goes further by disclosing exactly what is mutated (SaveData.MovesetIndex and MCP state) and that it returns a live-switch snippet. That is genuine behavioral context beyond the flags. It stops short of saying whether the previous moveset is recoverable or what the snippet format is.

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 compact sentence with the action front-loaded and the side effects trailing. Dense but every clause carries information; 'MCP state' and 'live-switch snippet' are the only jargon that could use unpacking.

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-required-param tool with no output schema, the description covers the action, the persistence target, and the return artifact, which is close to sufficient. Remaining gaps are modest: no statement about reversibility or how the returned snippet is meant to be applied.

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?

Only one optional parameter with 100% schema description coverage ('Optional filter on name/file'), so the schema already carries the semantics. The description adds no filtering syntax or scope detail, which is the expected baseline when schema coverage is high.

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 ('pick a random moveset') plus the two follow-on effects (persist, return snippet), which is far more than a restatement of the name. It implicitly separates itself from reanim_random_dance and reanim_switch_moveset via the moveset resource, though it never names those siblings to make the distinction 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?

No when-to-use guidance is given. With close alternatives like reanim_random_dance, reanim_surprise_me, and reanim_switch_moveset in the sibling list, an agent has no stated condition telling it which to pick, and there are no prerequisites or 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 declare readOnlyHint=false, so the mutation nature is already known, and 'Remove' is consistent with that. However, the description adds almost nothing beyond the annotation: it doesn't say whether removal is immediate/permanent, what happens if the name isn't present, or whether a re-add is needed to undo.

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 or repetition. It is efficient, though its brevity is partly what leaves the usage and behavioral gaps.

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, no-output-schema mutation this is close to sufficient, but it omits the failure mode (name not in favorites) and any cross-reference to the favorites listing/adding tools that would let an agent sequence calls 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 coverage is 100%, so both 'kind' (with enum dance/moveset) and 'name' are fully documented in the schema. The description mentions 'a name' but adds no format, casing, or enum context beyond what the schema already provides, making this a 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?

Names a specific verb ('Remove') and resource ('a name from the radial-wheel favorites'), so the action is unambiguous. It implicitly contrasts with the sibling reanim_add_favorite via 'remove', but never names the sibling or the list_favorites counterpart 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, no prerequisites (e.g. that the name should already exist in the favorites list), and no pointer to reanim_list_favorites for verifying entries. The agent must infer usage from the tool name alone.

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 destructiveHint=true and readOnlyHint=false, but the description adds real context beyond them: the destructive action is a timestamped move to a trash directory, the BuiltinModules tree is off-limits, and the change is reversible. It stops short of error behavior (missing file) or permission requirements, so it is not a full 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 short sentences with zero filler; the action, its scope limit, and the reversal path are all front-loaded.

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 mutation with no output schema and annotations that already cover the safety profile, the description covers what happens, what is protected, and how to undo it. It omits failure behavior for a nonexistent filename and whether the module must be inactive first.

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

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

Schema coverage is 100% and the schema already says 'Filename in Modules/', so the baseline is 3. The description goes slightly further by restating the Modules/ location constraint and explicitly excluding BuiltinModules, clarifying the valid domain of the single `file` argument.

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 (Move/Remove) and resource (a Modules/ file), and pins the exact mechanism (Modules/.trash/ with a timestamp). It also carves out scope (never touches BuiltinModules), which separates it from reanim_list_modules, reanim_get_module_info, and reanim_validate_module.

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: you call it to remove a module, and you undo it by moving the file back. There is no explicit when-to-use versus reanim_validate_module or reanim_get_module_info, and no stated preconditions (e.g. whether the module must be disabled or unloaded first).

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 and openWorldHint=false, so the description must carry the rest. It usefully discloses that this is a partial reset that preserves the LowEnd performance flag, a real behavioral nuance. It does not say whether the reset is reversible, whether a backup is needed first, or what happens to settings outside SaveData.Custom.

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 naming the target and the preserved exception, with no filler. 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 mutation with no output schema and readOnlyHint already set false, the description covers what changes and what is preserved. The one gap is reversibility/undo guidance, which matters for a destructive save-data operation.

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 clarify beyond the schema baseline. The description correctly spends no words on 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 (Reset) and resource (SaveData.Custom) plus the target state (script defaults), and adds a scope exception ('keeps LowEnd performance flag'). It contrasts implicitly with the sibling reanim_set_customization, though it never names the 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?

The name and verb make the use case strongly implied (restore customization to defaults), but the description offers no explicit when-to-use guidance, no contrast with reanim_set_customization, and no pointer to reanim_backup_savedata/reanim_restore_savedata before a destructive reset.

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=false and destructiveHint=true, so the safety profile is structured. The description adds genuinely useful context beyond that: the current file is auto-backed-up first and the backup is named 'pre-restore-*', which materially softens the destructive operation and tells the agent a recovery path exists.

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 a parenthetical, front-loading the list/restore duality and the auto-backup detail. Every clause carries information with no filler.

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

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

For a one-parameter tool whose annotations carry the destructive/readOnly profile and with no output schema, the description covers the essentials plus the auto-backup behavior. It stops short of describing the return format of the listing or restore result, but is otherwise 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 coverage is 100%, and the schema's own description ('Backup filename from the list, or empty to list') already documents the single parameter. The description's param hint ('Omit backup to just list') largely restates that, so the baseline of 3 is appropriate.

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

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

The description states a specific verb+resource ('restore one' / 'List Backups/') and its dual nature clearly, so an agent knows it both enumerates backups and restores them. It does not explicitly distinguish itself from the close sibling reanim_backup_savedata, but the restore-vs-backup verb distinction is inferable.

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?

'Omit backup to just list' gives an explicit condition that selects between the two modes of this tool. It does not name or exclude sibling tools (e.g., reanim_get_savedata or reanim_backup_savedata), so the routing guidance is clear but not exhaustive.

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 and openWorldHint=false, so the safety profile is covered. The description adds valuable behavior beyond that: case-insensitive matching, the ~14MB source scope, and that results are matching lines with line numbers, which tells the agent what a call yields.

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 verb and scope, with the return-format detail appended. 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?

With no output schema, the description usefully characterizes the return (matching lines with line numbers) and the search scope. It is nearly complete for a simple search tool, lacking only notes on pagination or query syntax (e.g. whether regex/wildcards are supported).

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% — the query param is documented in the schema, but limit is not. The description clarifies that 'N matching lines' corresponds to the limit parameter, partially compensating, but it omits the default (15) and max (50) bounds that shape the request.

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 resource (features in reanim.luau), plus the search semantics (case-insensitive). It is the only search tool among the siblings, so no sibling differentiation is needed, but it never names the resource as 'reanimator features' 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?

'Mimicking the V16 search bar' implies the intended usage of finding features by keyword, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative tool for related lookups.

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=false and openWorldHint=false, so the agent knows this is a mutating, local-scope operation. The description adds the partial-update behavior ('Only provided fields change'), which is genuinely useful and beyond annotations. However it doesn't state persistence, reversibility, or whether toggling is idempotent.

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 clauses, no waste, front-loaded with the verb and resources. The partial-update caveat is placed after the main action, which is appropriate.

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 3-param mutation tool with no output schema and zero schema description coverage, the definition covers the basics but omits persistence behavior, default state, and confirmation feedback. It's minimally viable but leaves gaps an agent might need.

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 maps the three params well by naming 'UI music, reanim/dance music, UI sounds' to MuteUIMusic, MuteReanimMusic, MuteUISound respectively, but it doesn't clarify boolean polarity (true = muted) or that omitting a field leaves it unchanged beyond the generic 'only provided fields' line.

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: mute/unmute three audio categories. It's distinctive from siblings like reanim_get_audio (read) and reanim_set_reanimator_settings (different settings domain). Slight ambiguity around 'reanim/dance music' naming but clear enough.

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

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

The phrase 'Only provided fields change' implies partial-update semantics, which is useful usage context. But there's no explicit when-to-use guidance vs siblings like reanim_get_audio or reanim_set_low_end_mode, and no stated 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 this is a write operation in a closed system (readOnlyHint=false, openWorldHint=false), so the safety profile is covered. The description adds real value with the validation contract ('Unknown keys are rejected') and the key enumeration, but says nothing about persistence, whether changes apply immediately or need a restart, or whether values are type-checked per key.

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

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

Two sentences, zero filler, and the enumeration of valid keys is front-loaded ahead of the rejection rule. Nothing needs trimming.

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

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

For a two-parameter mutation tool with no output schema and full schema coverage, the definition covers the essentials: what it writes, valid keys, and rejection behavior. What is missing is whether the change persists across sessions or requires a reload, and how it relates to the more specific sibling setters.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description's key list is slightly broader than the schema's examples (adds TriSpin, UIAnimSpeed, UIParticles, LowEnd), which is a marginal gain, but it adds no per-key value type or format semantics beyond 'New value'.

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 gives a specific verb ('Set') and a precise resource target ('any SaveData.Custom key'), so an agent can tell it is the mutating counterpart to reanim_get_customization and reanim_reset_customization. It stops short of explicitly naming those siblings or the namespace it writes to, but the operation itself 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 when-to-use or when-not-to-use guidance, and no routing to alternatives. This matters because 'LowEnd' is listed as a valid key here while a dedicated sibling (reanim_set_low_end_mode) exists, and UI keys overlap with reanim_set_ui_theme — the description resolves neither overlap.

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 say readOnlyHint=false and openWorldHint=false, leaving the real behavior unexplained. The description fills that gap with the crucial detail that the binding is written to MCP state and that the tool returns a Luau hint snippet rather than applying anything in-game — an agent would otherwise assume the keybind takes effect immediately.

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: the action, the key domain, the write target, and the return value all appear before any clause the agent must read twice.

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 helpfully states that the return is a Luau hint snippet, and both required parameters are covered by the schema. What remains thin is failure behavior (unknown key, unmatched dance name), which is not addressed.

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

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

Schema coverage is 100%: the key list and the dance-acceptance forms (substring, exact name, InternalName, 1-based index) are already documented in the schema. The description repeats the key slot list without adding syntax, precedence, or error behavior, so baseline 3 is correct.

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 a specific verb ("Bind") with a specific resource ("a dance to a key slot") and names the exact key domain, so it is instantly distinguishable from reanim_list_dance_keybinds. It also flags a non-obvious effect ("in MCP state") that separates it from reanim_switch_dance, though it never names those siblings 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 explicit when-to-use guidance, no prerequisites, and no alternatives named. An agent calling this alongside reanim_list_dance_keybinds or reanim_switch_dance gets no instruction on which to prefer or in what order.

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 and openWorldHint=false (a non-read mutation, non-open-world), so the description carries real weight. It usefully discloses the effects of each state — 'basic UI + simplified triangle' for ON and 'restores your settings' for OFF, implying previous settings are retained — which is added value beyond the annotation.

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 tight sentence with an em-dash separating the location hint from the state semantics; nothing is wasted and the core action is front-loaded. Minor cost from the 'Toggle' vs 'set' wording mismatch.

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

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

For a single-boolean, no-output-schema tool with full schema coverage, the description supplies enough to call it correctly, including both state effects. Only the when-to-use routing is missing.

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

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

Schema coverage is 100% and the schema already states true=ON / false=OFF, so baseline would be 3. The description goes further by explaining what each state actually does to the UI and settings, giving the agent semantic grounding for the boolean beyond a bare label.

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 (set/toggle LowEnd UI Mode) and even locates it in the UI (Main page > Performance). However, the description says 'Toggle' while the tool name is 'set_low_end_mode' and it requires an explicit boolean, so the framing is slightly inconsistent and doesn't differentiate it from siblings like reanim_set_root_mode or reanim_set_ui_theme.

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

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

No explicit when-to-use or when-not-to-use guidance, and no alternatives named among the many sibling setters. The UI path ('Main page > Performance') gives incidental context but doesn't help an agent decide when this tool is the right pick.

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=false (a mutation) and openWorldHint=false, so the safety profile is covered. The description adds the useful partial-update semantic ('Only provided fields change'), but says nothing about persistence, permissions, or what happens to unset keys beyond that single clause.

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 no filler, and the operation is front-loaded before the partial-update caveat. Sizing is appropriate, though brevity comes partly at the cost of missing 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?

A mutation tool with five parameters, no required fields, no output schema, and very low schema coverage needs more than two sentences. It omits valid ranges, what each SaveData key controls, whether changes persist, and what the response returns.

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 20% (just SelectedReanimator: '1 Limb, 2 Hats'). The description's field categories ('reanimator/movement/fling') loosely map to the parameters but give no units, bounds, or meaning for FlySpeed/WalkSpeed/FlingMethod/ClickFlingEnabled. It does not compensate for the 80% documentation 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 ('Update') and resource ('reanimator/movement/fling SaveData keys'), which is more than the title alone. It is clearly the write counterpart to reanim_get_reanimator_settings, but it never names that sibling explicitly to differentiate.

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. The only operative clause, 'Only provided fields change,' is a behavioral detail, not routing. An agent must infer that the get_* sibling is the read path.

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 and openWorldHint=false; the description adds that the operation persists state and returns a live bridge snippet, and discloses the re-run-to-load-plugins side effect. That is meaningful behavioral context beyond the annotations, though permissions/reversibility are unstated.

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, front-loaded with the core action and value forms, with the re-run caveat placed last. The embedded snippet identifier is dense but informative rather than wasteful.

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 action, accepted inputs, persistence, and the returned snippet plus re-run behavior. Enough for an agent to call it correctly; only permission and error semantics 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 100%, so the schema already documents 'mode' (index/name/plugin) and 'velocity' (0-2). The description largely restates the mode value forms and adds little syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Persist a RootPart mode pick') and enumerates accepted value forms (builtin 0-6 by index/name, active plugin by name). It is clear what the tool does, though it does not explicitly contrast itself with the sibling plugin or settings 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?

The closing line 'Re-run to load newly enabled plugins' implies the tool should be re-invoked after enabling a plugin, which is useful context. However, it names no alternatives and gives no explicit when-not guidance relative to reanim_enable_root_plugin or reanim_get_root_settings.

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 and openWorldHint=false. The description adds real value by disclosing that changes persist to SaveData.Custom and that a return 'apply snippet' is produced, which tells the agent about side effects and output 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 front-loaded sentences with no filler, opening on the verb and resource before listing the parameter groups. The parameter dump is dense but tightly sized for a 10-parameter tool.

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

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

A 10-parameter mutation tool with no output schema and only 30% schema coverage. Persistence and return behavior are covered, but the meaning of most numeric modes and color parameters is absent, leaving the agent under-informed 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 description coverage is only 30%, so the description must compensate. It restates parameter names and the AccentMode/HarmonyMode ranges that the schema already provides, but leaves TriColorMode, IntroColorMode, ColorSat/Speed/Bright, and IntroColor unexplained in either place.

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 ('Change UI theme') and names the parameter families involved. It does not explicitly distinguish itself from close siblings like reanim_apply_theme_preset or reanim_set_customization, so it is clear but not fully differentiated.

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 and no mention of alternatives, despite obvious candidates such as reanim_apply_theme_preset or reanim_set_customization. The agent gets no condition that selects this tool over its 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 already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, local read. The description adds the scope of what is checked, but says nothing about the shape of the result, cost, or what a failed check implies. With annotations carrying the safety profile, this is adequate but not rich.

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, and the primary function is front-loaded ahead of the usage hint. It could be marginally tighter but nothing is wasted.

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

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

For a read-only, zero-parameter status tool with no output schema, the description covers what is inspected but never characterizes the returned status or counts. An agent can invoke it correctly but has only a rough idea of what it will get back.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing parameter-related for the description to compensate for. Schema coverage is also reported at 100%.

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 (Check) and enumerates the resources it inspects (reanim.luau script, workspace, SaveData, module counts), so the agent knows this is a setup/health check. It does not clearly differentiate from the sibling reanim_doctor, which likely serves a similar diagnostic purpose, so it falls short of 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?

"Use first to verify setup" gives an implied when-to-use and even an ordering hint, which is more than nothing. However, it names no alternative (e.g., reanim_doctor) and states no exclusions, so the routing guidance is only partially 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 only declare readOnlyHint=false and openWorldHint=false; the description adds real behavioral context: it clears the current dance and returns Luau (i.e., emits a script rather than performing the action directly) via a UI Stop button or a keybind re-press fallback. That fallback logic and mutation side effect go meaningfully 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?

A single front-loaded sentence with the parenthetical supplying the mechanism; nothing is padded. Slightly dense, but 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 no-param tool with mutation annotations and no output schema, the description covers the action, its side effect, and the fact that it returns Luau. It could say more about what the returned Luau is for or whether clearing is reversible, but it is largely sufficient.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There are no parameters for the description to clarify or omit.

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+resource ("Clear MCP current dance" and "stop dancing"), which reads clearly as the inverse of reanim_switch_dance. It is unambiguous what the tool does, though it never explicitly names a sibling to contrast with.

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 alternatives (e.g., switch_dance or random_dance). The purpose implies its use, but no conditions or exclusions are given, matching the 'no guidance' band.

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=false, so the agent knows this is a mutating, closed-world call, but the description does not say what actually changes: whether the current dance and theme are overwritten, whether it applies or merely previews the combo, or whether prior settings are recoverable. For a 'surprise me' action tool that likely clobbers current state, this ambiguity is a real gap. No annotation contradiction, but little added behavior context.

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 or repetition. It is appropriately sized for a no-argument action, though it is terse enough that it could have absorbed one clarifying clause without becoming bloated.

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 mutating tool with no output schema, the description leaves the main agent questions unanswered: whether the combo is applied permanently, what happens to existing dance/theme state, and where the results are surfaced. The annotations cover the safety profile but the description does not finish the job.

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 coverage is 100%, so there is nothing for the description to compensate for. Baseline for a no-param tool applies.

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

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

The description names a concrete composite action: a random dance plus a random theme preset, with live snippets. The word 'combo' usefully differentiates it from the sibling reanim_random_dance and reanim_random_moveset, which each randomize only one thing. It stops short of stating that sibling relationship explicitly, so it is clear but not maximally differentiated.

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

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

There is no when-to-use guidance at all. An agent cannot tell from the description when to pick this over the simpler reanim_random_dance, reanim_random_moveset, or the manual reanim_apply_theme_preset path. No prerequisites, no exclusions, no alternatives are mentioned.

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 and openWorldHint=false, so the description carries the interesting burden and does so well: it reveals that the tool records internal MCP state and returns Luau code that performs the actual UI click externally, rather than clicking directly. It stops short of describing the returned snippet's structure or failure behavior.

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

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

Two tight sentences with zero padding; the core purpose and the state-mutation/return behavior are front-loaded, and the identifier rules are packed into a single follow-up clause.

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 covers what it does, what it returns (executor-ready Luau), and where identifiers originate. It leaves minor gaps around what the generated Luau does on failure or how many results it produces, but nothing an agent needs to call it correctly is missing.

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 single 'dance' parameter is already fully documented, including the four accepted forms. The description largely repeats this and only adds the useful pointer that identifiers come from reanim_list_dances, which is the baseline-plus level.

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 ('Record a dance pick... clicks the matching Dances UI entry') and even discloses the dual behavior of persisting state plus emitting executor-ready Luau. It is far more specific than the title 'Switch dance'. It does not, however, explicitly separate itself from adjacent siblings like reanim_random_dance or reanim_get_current_dance.

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: the agent can infer this is the tool for selecting a specific dance, and it points to reanim_list_dances as the source of identifiers. There is no explicit when-to-use/when-not guidance and no named alternative for cases like random selection.

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 safety profile (not read-only, idempotent, non-destructive, closed-world), so the bar is lower. The description goes beyond them by disclosing exactly what is mutated (SaveData.MovesetIndex and MCP state) and that the tool emits executable Luau that clicks the UI live — non-obvious side effects an agent should know about.

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 no filler; the persist-and-return behavior leads and identifier guidance follows. Slightly 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?

For a single-parameter mutation tool with no output schema, the description covers purpose, persisted state, and the Luau return value. Minor gaps remain (behavior on ambiguous or invalid identifiers, whether an executor is assumed), but nothing critical for correct invocation is missing.

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 sole 'moveset' parameter is already fully documented in the schema. The description restates the same accepted forms (name substring, InternalName, 1-based index) without adding new syntax or disambiguation rules, so the baseline 3 applies.

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

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

States a specific verb (persist/switch) and resource (moveset), plus the two concrete effects: writing SaveData.MovesetIndex + MCP state and returning executor-ready Luau that clicks the Movesets UI entry. This clearly separates it from siblings like reanim_list_movesets, reanim_create_moveset, and reanim_get_current_moveset.

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?

Points at reanim_list_movesets as the source of valid identifiers, which implicitly tells the agent to list before switching. However, it never states when to prefer this over alternatives such as reanim_random_moveset, nor any preconditions or exclusions — usage is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that by enumerating what the lint inspects, but it says nothing about how failures are reported (error list vs thrown exception) or whether validation is strict or advisory.

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 core action front-loaded and the check list appended; there is no filler text 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 single-parameter, read-only lint tool with annotations covering safety, the description is nearly sufficient. The one remaining gap is the return format of diagnostics, which is not covered by an output schema or by the description, though the enumerated check categories partially compensate.

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% and the single 'file' parameter already documents that it accepts a filename in BuiltinModules/ or Modules/ or a full path. The description adds no further parameter detail, so the baseline 3 applies.

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

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

The description names a specific verb (Lint) and resource (a module file), then enumerates the exact checks performed: block balance, required m.* fields, factory-array return, duplicate names vs catalogue. This level of detail cleanly separates it from siblings like reanim_check_module_assets, which validates assets rather than module source 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?

There is no when-to-use guidance, no precondition (e.g. before enabling a module), and no mention of the alternative checks (reanim_check_module_assets, reanim_get_module_info) or when each is appropriate. The usage is only inferable from the tool name and the enumerated checks.

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