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

Goes far beyond the destructiveHint/readOnlyHint annotations: it discloses that NONE deletes imported materials, that object_type has no default because MPFB's default silently mislabels, that fragment resolution is by basename and can collide, that fitting/delete-group are unconditional, and it enumerates the refusal codes (added:false with blocked_by). This is unusually rich behavioral disclosure.

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

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

Front-loaded with purpose and then a bolded critical prerequisite; the dense parameter-by-parameter paragraphs each earn their place given 10 params at 0% schema coverage. It is on the long side and a few sentences pack multiple facts, but there is little outright waste.

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

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

For a 10-parameter, non-idempotent, destructive mutation, the description covers prerequisites, parameter semantics, side effects, and failure modes. It even summarizes the success result fields, though an output schema exists, so nothing an agent needs 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 0%, so the description must carry parameter meaning and it does: object_type required with exact enum values, path XOR fragment exclusivity, material_type's four values and per-type defaulting, subdiv_levels controlling render vs viewport level, and the four MPFB-default flags. Almost every one of the 10 parameters is explained.

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?

Opens with a specific verb+resource ('Equip a MakeHuman character with one mesh asset from an MHCLO') and enumerates the asset kinds covered. It also implicitly distinguishes itself from siblings by naming mpfb_remove_asset and mpfb_set_asset_material as the follow-up/adjustment 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?

Explicitly states the ordering prerequisite ('Rig the character before dressing it', with the consequence of not doing so), names the alternatives for material changes ('mpfb_set_asset_material'), and tells the agent when to consult mpfb_list_assets for object_type/path/fragment values.

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 destructiveHint=true and non-idempotent, and the description richly extends this: basemesh is moved to origin, rig cannot be swapped (already_rigged), refusals surface as added:false with blocked_by codes, weights resolution via fallback table. Goes well beyond what annotations alone 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?

Front-loaded with the core action and prerequisite, which is good, but the body digresses into a full enumeration of result fields (weights_from/weights_path, basemesh_location_before, etc.) that belong to the output schema. Dense but partially redundant with structured data.

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

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

Given a stateful mutation tool with an output schema present, the description still supplies the non-obvious behavioral contract: metarig semantics, origin relocation side effect, refusal taxonomy, and non-swappable rigs. Comprehensive for the agent's decision needs.

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

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

Schema coverage is 0% and there are three parameters, so the description carries the full burden. It precisely defines 'identifier' format and its prefix-selection semantics, and explains import_weights' effect (weights+modifier vs. parenting only) - substantially more than the schema provides.

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 ('Attach a rig to an existing MakeHuman character') and immediately clarifies it maps to MPFB's three adding operations. Distinguishes itself from siblings like mpfb_generate_rigify_rig by explaining the metarig handoff.

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?

Explicit prerequisite ordering ('Rig the character before dressing it'), explains the consequence of violating it (mesh_assets_not_rigged), and names the follow-up tool (mpfb_generate_rigify_rig) for the rigify case. Also names sibling mpfb_list_rigs as the source of valid identifiers.

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?

Far exceeds the annotations (readOnly=false, destructive=true, idempotent=true). It discloses atomicity ('Nothing is written unless every fragment resolves'), the refusal shape (blocked_by: unresolved_fragments), a pack prerequisite (faceunits01), the destructive consequence that face units composed via mpfb_set_face_units are discarded, and clamping behavior. This tells the agent exactly what gets destroyed and when it will refuse.

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?

Dense but well-organized into paragraphs covering semantics, refusals, destructive effects, and return fields, with bolded emphasis on the sharp edges (weight 0.0 removes, replace with empty list clears all). It is long, but the length is justified by the tool's complexity and the missing schema descriptions.

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 complicated mutating tool with an output schema, the description still adds useful return-value detail (changed, requested actions, applied_applied_expressions, discarded_face_units, panel_synced) and full failure-mode coverage. The only incompleteness is the undocumented 'name' parameter and the lack of an explicit alternative-tool comparison.

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% with 4 params, so the description must carry the burden. It richly documents expressions ({fragment, weight}, 0.0-1.0, weight 0.0 removes), mode (merge vs replace, empty-list semantics), and refit, but the 'name' parameter is never mentioned anywhere, leaving one param fully unexplained — a real gap against 0% 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?

States a specific verb and resource ('Put a MakeHuman character into saved expressions') and names the exact mechanism (MPFB's applied-expressions stack). It distinguishes itself from siblings like mpfb_set_face_units and mpfb_list_expressions by describing the stack-based route and that the result survives mpfb_save_preset.

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

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

Gives clear context for use and a critical ordering prerequisite ('call mpfb_save_expression first to keep them' before face units are discarded). It references mpfb_list_expressions for fragment format and mpfb_save_preset for durability, but stops short of explicitly stating when to prefer this over the sibling face-unit 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 only supply destructiveHint=true, so the description carries most of the burden and delivers: it discloses the non-normalization of race weights, the effect of `scale` on later skin rendering, which create_human() defaults are silently used for unexposed parameters, and that creation 'either succeeds or raises'. It does not explicitly address the destructiveHint or scene-level side effects, but the disclosure is well 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?

Long, but front-loaded with purpose and workflow before parameter semantics and return values; each paragraph carries distinct information. Slightly verbose in places (e.g. the 'without relearning the vocabulary' aside), but nothing is 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?

Despite an output schema existing, the description still explains the key result fields (basemesh_name as the address later tools need, vertex_count, location, macro_detail_dict) and the performed flag. Combined with full parameter semantics and workflow placement, an agent has everything needed to call it correctly.

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

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

Schema coverage is 0%, and the description fully compensates: it lists all eleven macro sliders, their 0.0-1.0 range, per-slider neutral values (0.5 except 0.33 for the three race weights), the meaning of age and gender endpoints, and the semantics of `scale` as a basemesh scale factor.

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 ('Create a new MakeHuman character - a basemesh with a phenotype') and names the underlying service call. It differentiates itself from several siblings (mpfb_set_macro_details, mpfb_add_rig, mpfb_add_asset, mpfb_set_skin) and positions itself as the starting point of the character workflow.

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 explicit ordering guidance ('rig it before dressing it') and an explicit when-to-use-this-vs-alternative rule: 'Set the phenotype in this call when you know it; use mpfb_set_macro_details to change one afterwards.' It even spells out the semantic difference in omitted parameters between the two 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?

Goes well beyond the annotations: states it adds a character without altering existing scene content, warns execution takes seconds not milliseconds, discloses that the selection is not restored, flags that unresolved_assets silently drops missing assets, and enumerates every blocked_by refusal including the non-atomic deserialization_failed partial-build case.

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?

Long but dense and front-loaded: the core purpose and the 'not load into current character' caveat come first, then a bulleted parameter block, then the result/refusal sections. Nearly every sentence carries actionable information, though the volume of return-value detail edges past what strictly needs to be in the description.

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, non-idempotent, potentially partial-failure mutation tool with 0% schema coverage, the definition supplies everything needed: parameter semantics, defaults, valid ranges, silent-failure warnings, refusal taxonomy, and retry guidance. Nothing an agent needs to invoke 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?

With 0% schema description coverage, the description carries the full burden and delivers: preset_name is a name not a path, all override_* fields default to null meaning 'use the preset', scale units are given (0.1 m default, 1.0 dm, 10.0 cm), and the material_instances_policy default is documented with its divergence from the service default.

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 new character from a saved MPFB preset') and enumerates the asset classes it covers (phenotype, targets, rig, garments, skin, eyes). It explicitly differentiates itself from the sibling concept of loading into the current character, so an agent can distinguish it from mpfb_create_human and mpfb_add_asset.

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

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

Explicitly names when to use it versus alternatives: mpfb_list_presets for valid names, mpfb_list_rigs for rig identifiers, mpfb_generate_rigify_rig to finish a meta rig, mpfb_set_skin for skin_type values, mpfb_add_asset for material_type values. It also gives a retry path (use override_rig) when deserialization_failed occurs.

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 destructive/non-idempotent, and the description adds substantial context beyond them: it is not undoable, cannot restore selection, re-parents and re-weights existing assets, and deleting the meta rig makes the character permanently unrefittable. It also warns that 'generated: false does not mean nothing happened' and enumerates blocked_by refusal reasons.

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

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

Front-loads the core action, then prerequisites, parameter semantics, return shape and failure modes in a logical order. It is long and somewhat dense with bolded clauses, but given the destructive, non-undoable nature and zero schema coverage, nearly every sentence 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?

Complete for a destructive, non-undoable tool: it covers prerequisites, parameter resolution quirks, meta-rig disposition, post-conditions, and the full set of failure reasons. The output schema exists, yet the description still names key result fields, which is redundant but not harmful.

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 0% schema description coverage, the description carries the full burden and does so: it clarifies that name resolves to the meta rig (not basemesh), that generated_rig_name is a basename with an MPFB fallback when omitted, and that meta_rig_action accepts keep/hide/delete with default 'hide' and distinct scene effects.

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

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

States a precise verb and resource: turning a character's Rigify meta rig into a generated, poseable Rigify rig. It explicitly positions itself against the sibling that precedes it ('the second step of the two mpfb_add_rig starts'), so an agent can tell the two apart without opening either schema.

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

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

Gives an explicit precondition ('Attach the character's garments and other mesh assets before calling this') and explains the consequence of ignoring it. It also names the related sibling mpfb_refit_human and the condition under which this tool's action breaks it, and recommends a default ('Prefer "hide"').

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 readOnly/idempotent/safe, but the description goes further: it explains the miss behavior ('found is false and every section is null or empty'), the truncation flag semantics ('rollup_truncated', 'modifier_count gives the whole'), and a genuine side-effect warning that a non-empty unexplained_face_units is work destroyed by a later call. That last point is behavioral context no annotation could carry.

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

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

Front-loaded with the one-line purpose and a change-nothing guarantee, then a clean per-section breakdown. It's longer than most definitions but every bullet maps a section to its source tool and its caveats, so it earns the space. Minor redundancy across the 'read by the same code' framing.

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 composite read tool with an output schema, it fully explains the section structure, provenance, truncation, and null/miss semantics, and even links the state to the next mutation tool. An agent knows exactly what it will receive and what a follow-up apply would risk.

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

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

Schema coverage is 0% and the only parameter (name, nullable with default null) is undocumented in the schema. The description never explains what name means or what a null/omitted name does, so it doesn't fully compensate. It's better than baseline only because the surrounding text implies single-character target selection.

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 ('Summarize one MakeHuman character') and scopes it to pre-modification reconnaissance with 'before changing it.' Clearly distinguishes itself from the detailed getters it delegates to by declaring the read-first role.

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

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

Explicitly states when to use it ('Call this first') and routes to alternatives only when needed ('call a detailed tool only for what the summary leaves out'). Lists the exact detailed tools each section maps to, giving the agent an unambiguous triage 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 already cover read-only/idempotent/non-destructive, yet the description adds substantial context beyond them: unresolvable rows contribute nothing to the face, matches_stack false means composed work that the next apply/preset load will overwrite while mpfb_save_expression keeps it, and an unresolvable subject yields found:false rather than an error. This is rich behavioral disclosure that the annotations do not carry.

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

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

Front-loads the purpose well, but the bulk of the text re-describes output-schema fields (applied_expressions rows, aggregate, clamped_face_units, matches_stack, unexplained_face_units) that the output schema already carries. That duplication dilutes conciseness for a two-parameter getter.

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

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

Given an output schema exists, the description goes beyond requirement by narrating return values and edge cases (unresolved_count, found:false, basemesh_name), which makes it complete for the read operation. The only gap is the 'name' parameter's meaning, which neither description nor schema clarifies.

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 explains 'refresh' ('re-probes for it') but gives no explicit meaning for 'name' as a parameter – it only indirectly implies the subject via 'An unresolvable subject is found: false'. Partial compensation warrants 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?

States a specific verb and resource ('Read which saved expressions a MakeHuman character is wearing') and scopes it to the applied-expressions stack. It also explicitly differentiates itself from a sibling ('For the raw live face-unit values, call mpfb_get_face_units; this tool reports only how they differ from the stack').

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?

Names the alternative tool (mpfb_get_face_units) and the condition that selects it, and clarifies the scope difference from the raw live values. It also places the tool within a workflow by naming mpfb_set_face_units, mpfb_apply_expressions and mpfb_save_expression as the things that touch the 'composed work'. No explicit when-not beyond the alternative, so it falls short of 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 readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: read values are cached for the Blender session, unresolved subjects return found:false rather than an error, and faceunits01_installed disambiguates 'neutral face' from 'pack not installed'. This is rich behavioral disclosure.

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

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

Purpose is front-loaded, then structured paragraphs cover the result shape, always-present fields, and the found:false semantics. Dense but each sentence carries information; slightly verbose in places but not 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 read tool with three optional params and an output schema, the description covers return fields, defaults, error-vs-answer semantics, cache behavior, and region groupings. 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 coverage is 0%, so the description must carry parameter meaning. It explains include_zero (default false -> all 52) and refresh (default false, busts the session cache) well; name is only implied via 'a subject that cannot be resolved', which is a minor 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?

The first sentence states a specific verb (Read) and resource (ARKit face units on a MakeHuman character's face), and explicitly frames it as the read counterpart to mpfb_set_face_units. An agent can distinguish it from siblings without opening the schema.

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

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

It names the counterpart write tool and gives conditions for the two flags (refresh when the pack was installed after Blender started; include_zero for all 52 units). It does not exclude scenarios explicitly, but the context is clear enough for correct 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 readOnly/idempotent/non-destructive, yet the description adds substantial context beyond them: 'Changes nothing', the non-error failure contract ('found: false' with a 'message' for unresolvable names, no active object, or no basemesh), and the drift-detection semantics linking this tool to the setter's repair 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?

Front-loaded with purpose and the key call-ordering rule, then organized into scannable bulleted result fields. It is long and much of the return-field inventory is duplicated by the existing output schema, but the non-obvious semantics (unnormalized race weights, drift, target-vs-input vocabularies) genuinely earn the space.

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

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

Given an output schema, a single name parameter, and a subtle setter relationship, the description covers purpose, ordering, failure modes, field interpretation, and the traps (race weights summing above 1.0, stale shapekeys, mesh tagged as basemesh but never built). 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?

One parameter at 0% schema coverage, but the description compensates by explaining name resolution and the 'subject_resolved_by' ('name' or 'active') fallback, plus that an unresolvable name yields 'found: false' rather than an error. It covers the resolution contract well, though it never states the default-when-omitted behavior explicitly for the agent.

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 ('Read a MakeHuman character's macro details - its phenotype sliders') and immediately enumerates the exact sliders returned. An agent can distinguish it from mpfb_get_character_summary or mpfb_get_target_stack without opening any schema.

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

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

Explicitly says 'Call this before `mpfb_set_macro_details`' and explains why: the setter leaves unnamed sliders alone, so current values are needed to make a relative change like 'a bit older'. This is a concrete when-to-use plus a named alternative, not implied guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavioral context: the three result sections, the `applies:false`+`reason` convention, the null-for-other-sections behavior, the ~20 KB payload warning, linked sockets that writes cannot change, and shared materials that a write would also affect. This is well beyond what the annotations carry.

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

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

The description is long and dense, but the core purpose is front-loaded and each subsequent block (result sections, per-node keys, color-adjustment record) earns its place given the tool's complexity. Some nesting/bullet detail is verbose but not 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?

Despite an output schema existing, the description documents the return shape in depth (sections, per-node keys, linked sockets, ranges, color-adjustment fields), which is essential for a read tool whose output drives a subsequent write. 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 0%, so the description must carry both params. `section` is fully explained (valid values, that it reads one section and nulls the others). `name` is only indirectly characterized via 'the preset's key' and 'an unresolved subject is found:false', leaving its exact semantics slightly inferential, but the compensation is largely effective.

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 opening sentence gives a specific verb (read), resource (procedural material settings), and scope, explicitly anchoring it to the sibling `mpfb_save_preset` and the counterpart `mpfb_set_material_settings`. 'Changes nothing' removes any ambiguity about mutation, and an agent can distinguish this from set_material_settings/save_preset without opening a schema.

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

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

It states its role in the read-modify-write workflow ('exactly what mpfb_save_preset saves ... for mpfb_set_material_settings to change'), which effectively tells the agent when to reach for it. It stops short of explicit when-not conditions or a direct alternative comparison, but the context is clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description reinforces it with 'changes nothing, selects nothing.' Beyond that it discloses real behavioral nuance - that `found: false` is a normal outcome, that the active object shifts as the user clicks, and that a resolved name may not appear in mpfb_list_objects.

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 well front-loaded and bullet-structured, but it is very long and a large fraction of it documents `result`/`asset_info` field semantics that the existing output schema already covers, so several sentences do not earn their place in a tool description.

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

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

Given a single optional parameter, an output schema, and rich annotations, the description is more than complete - it covers calling modes, resolution failure, and edge cases (null fragment vs null path, .proxy suffix) with nothing an agent would need left out.

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 single parameter has 0% schema coverage, and the description fully compensates: `name` is defined as a Blender object name, its default/omitted behavior is spelled out, and the consequence of not resolving a subject is explained.

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 opening states a precise verb+resource: identify one Blender object, name its MakeHuman source asset, and list related objects, plus the explicit non-effects ('Changes nothing, selects nothing'). It also anchors itself against the sibling mpfb_list_objects as the source of valid names.

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

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

It clearly explains the two calling modes (pass `name`, or omit it to inspect the active object) and how to obtain names from mpfb_list_objects. It even recommends re-calling to walk the hierarchy, but it never states when to prefer this over the sibling mpfb_get_character_summary.

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

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive), but the description adds substantial context beyond them: the three normal `state` values with their meanings, that none of them are errors, the double-installation signal from `candidate_modules`, and the instruction to re-call rather than cache scene-scoped fields. This is rich disclosure; the only slight gap is no note on failure/latency 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?

Front-loaded purpose and usage sentence followed by clearly structured bullet lists. It is verbose in enumerating result fields, which is partly redundant given an output schema exists, but every line carries real semantic meaning (e.g. what each state value implies).

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 diagnostic tool this is complete: it explains purpose, when to call, what each state means, the double-install signal, and the caching caveat. Nothing an agent needs to call and interpret this tool 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?

The tool has zero parameters, so the baseline is 4. The description confirms 'Takes no arguments', aligning with the empty schema; there is nothing further to document.

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 ('Report') and resource ('whether MPFB is loaded and usable... and how it is configured'), clearly differentiating it from every sibling, which all mutate or inspect scene data. An agent immediately understands this is the diagnostic/health-check tool.

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

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

Explicitly prescribes when to call it: 'Call this first when any other MPFB tool fails unexpectedly,' and explains exactly why it is preferable to the bare error the other tools emit. There is no competing alternative, and the trigger condition is unambiguous.

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?

Despite annotations already declaring readOnly/idempotent/non-destructive, the description discloses a great deal more: the 200-default/1000-max cap, the never-paged/never-filtered behavior of the modifiers view, the found:false-not-error contract, that drifted macro values are reported rather than repaired, and the invisible 'basis'-containing shape keys MPFB cannot see. This is exactly the kind of behavior beyond annotations the dimension rewards.

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

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

Front-loaded with the core purpose and well-structured with bolded section headers. It is long and spends substantial prose enumerating result fields (targets, modifiers, asymmetries) that the existing output schema already defines, which is some duplication, though most sentences still carry semantic value.

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 six-parameter read tool with a rich output schema, the description covers the truncation contract, inclusion flags, filtering, edge cases (unresolvable subject, drifted macros, invisible keys), and the dual addressing model. An agent would not need to guess at call semantics or failure behavior.

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

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

Schema coverage is 0%, so the description must carry the burden, and it does well for include_macro, include_expressions, limit (default 200, cap 1000), and name_contains. However `name` and `offset` are never explained, leaving two parameters undocumented in both schema and description.

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

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

States a specific verb and resource: 'Read the modeling targets currently applied to a MakeHuman character - every shape key on its basemesh, and the modeling sliders they add up to.' It explicitly contrasts itself with siblings by naming the write counterpart (mpfb_set_targets), the macro-subject tool (mpfb_get_macro_details), and the downstream consumer (mpfb_symmetrize_targets).

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

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

Gives clear operational context: read truncated/total_count before concluding a target is absent, and 'narrow with name_contains rather than paging blindly.' It also frames asymmetries as the input that makes mpfb_symmetrize_targets informed. It never states an explicit when-not-to-use or a strict alternative-selection rule, so it stops 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?

Despite annotations already marking it read-only and idempotent, the description adds substantial non-obvious behavior: the per-asset cache that is never auto-invalidated, that refresh=true clears every asset's cache globally, and that non-asset objects return found:false rather than an error. This is exactly the kind of context annotations cannot carry.

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

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

The opening is well front-loaded, but the middle paragraph enumerates `result` fields (path, fragment, name, is_default, count, search_roots, cache_invalidated) in detail even though an output schema exists, which is largely redundant verbosity. Some of it (why search_roots matters, the default not being filtered) earns its place, but the passage is longer than needed.

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 listing tool with a modest two-parameter schema, the description covers the input source, cache semantics, output shape interpretation, and error-avoidance behavior. An agent has everything needed to call it correctly and interpret ambiguous results.

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 0% schema description coverage, the description must compensate, and it does: `name` is defined as the asset's own Blender object name with the exact sibling calls that produce it, and `refresh` is explained as a cache-clearing flag whose effect is global, justifying the false default.

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 ('List the alternative materials that ship beside one equipped MHCLO asset') and immediately clarifies scope. It explicitly distinguishes itself from mpfb_list_assets by noting that tool covers library sections, not an asset's own directory.

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?

Names the siblings that relate to it: mpfb_list_assets (which does not cover this), mpfb_set_asset_material (which consumes this output), and mpfb_list_objects/mpfb_add_asset as the source of the `name` argument. It also states the cache/refresh tradeoff so the agent knows when to pass refresh=true.

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 it a safe read, so the bar is lower, and the description still discloses rich behavior: results are capped and usually a subset, truncated/total_count flags must be checked, first call per subdir is slow due to preview-image loading, refresh rescans the whole library and writes caches, and cache-keying can collapse entries and under-report totals. This is far beyond the readOnly/idempotent annotations.

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

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

Front-loaded with a one-line purpose and the capped-answer warning, then a structured argument list and a return-shape section. It is long, but every block is load-bearing for a tool with 6 undocumented parameters and a complex result object. Marginally more verbose than strictly needed but not 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?

Even with an output schema, the description explains how to interpret result fields (truncated, total_count, counts_by_asset_subdir, asset_roots_searched) and the naming model (path vs fragment, object_type). For an asset-listing tool whose correctness depends on paging and cache subtleties, this is complete enough to call and interpret correctly.

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

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

Schema description coverage is 0%, so the description must compensate and it does: it documents every parameter (asset_subdir enum values, name_contains substring semantics, pack directory-convention derivation, limit default/max, offset, and when refresh is needed) plus how parameters combine (AND). It adds meaning the bare schema completely lacks.

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

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

States a precise verb+resource ('Find the MakeHuman assets installed in this Blender') and enumerates the asset categories. Explicitly distinguishes itself from siblings: it contrasts with mpfb_get_object_info (the reverse direction) and routes skin assets to mpfb_set_skin and application to mpfb_add_asset.

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

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

Gives clear when-to-use context (before applying an asset, to check what is installed), names the exact sibling tools to use downstream (mpfb_add_asset, mpfb_set_skin), and explains edge cases like 'I installed it and it is not listed'. No alternative is left implicit.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: it changes nothing, needs no Blender/MPFB, and critically 'fetches nothing' — returning URLs rather than content. It also discloses the curated-subset constraint, the master pinning caveat, and the unknown-topic 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?

Front-loaded with purpose and organized with bold labels and a bulleted result listing, so it is scannable despite its length. Each sentence carries information, though the result-field inventory is dense enough to verge on over-long for a list 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?

An output schema exists, yet the description still maps the return fields and, more importantly, documents the two otherwise-undocumented parameters and the topic_recognized pitfall for empty results. 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 coverage is 0%, so the description carries the full burden and does: it enumerates the exact accepted topic values (general, services, fileformats, entities, ui), their matching semantics (exact, case-insensitive), keyword's substring scope over four fields, and the no-argument fallback. This is richer than the empty 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 resource (MPFB developer documentation addresses) and enumerates exactly what it covers (per service, per file format, object property store), plus a concrete use case ('how does MPFB actually do X'). It is unmistakable against siblings like mpfb_list_urls or mpfb_get_object_info.

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

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

Explicitly frames when to reach for it ('rather than inferring it from a tool response') and routes the agent onward when the curated subset is insufficient ('go there when what you need is not here, rather than concluding it does not exist'). No named sibling alternatives, but no real doc-lookup sibling exists to contrast with.

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 readOnly/idempotent/destructive/openWorld, but the description adds substantial context beyond them: the file scan is never cached, refresh only re-probes the asset pack, unreadable files are skipped for parse failures, and shadowed files cannot be applied. These are real behavioral traits 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?

Front-loads purpose and the sibling relationship in the first sentence, then organizes output/roots/constraint details in labeled paragraphs. It is longer than strictly needed given an output schema exists (field-by-field enumeration is partly redundant), but each block adds semantics and nothing is wasted.

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

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

Given a one-param list tool with an output schema, the description covers purpose, the routing to apply_expressions, output field semantics, directory scanning order, skip/shadow behavior, and the mandatory faceunits01 constraint. Nothing an agent needs to call or interpret 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 coverage is 0% for the single 'refresh' parameter, so the description must compensate, and it does: it explains refresh re-probes for the faceunits01 asset pack while the file scan is never cached. That meaningfully extends the bare boolean/default in 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 (List) and resource (saved expressions), defines what an expression actually is (named, weighted combinations of ARKit face units), and explicitly ties it to the sibling mpfb_apply_expressions as the consumer. An agent can distinguish this from mpfb_get_expression and mpfb_apply_expressions immediately.

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

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

The description routes the agent clearly: this is the lookup that produces the 'fragment' identifier mpfb_apply_expressions takes, and 'Changes nothing' signals a safe read. It stops short of an explicit when-to-use/when-not statement or naming alternative list tools, so 4 rather than 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, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description goes well beyond that: it discloses the case-insensitive substring matching semantics (with the 'not a bug' caveat), the scene-vs-.blend linkage distinction, the empty-list/typo ambiguity, and the staleness caveat about re-calling rather than caching. These are non-obvious behavioral traits an agent would otherwise discover the hard way.

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

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

Front-loaded with the core purpose and the safety statement, then builds outward to usage, matching semantics, scope caveat, result shape, and staleness. The matching-semantics paragraph is dense but every clause adds actionable information. Slightly long for a one-parameter list tool, but no true 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?

Covers purpose, routing, matching semantics, scope limits, result fields including the critical object_type_recognized flag and known_object_types, and the cache-invalidation caveat. Even without an output schema being relied on here, the description explains the response structure completely enough that an agent can interpret an empty result correctly.

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

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

Schema description coverage is 0% and the parameter has no enum, so the description must carry the full burden. It does: it lists all eleven MPFB type names, states that omitting it returns everything, and explains the substring-matching semantics with concrete examples ('rig' matches Subrig). That is far more than the schema provides.

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 the MakeHuman objects in the connected Blender's current scene'), scopes it to the current scene, and distinguishes itself from mpfb_get_object_info by naming that sibling and describing its role in the workflow. No ambiguity about what it does.

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

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

Explicitly states when to use it ('to find a subject for the other MPFB tools when you did not create the character yourself') and what to do next ('pass a returned name to mpfb_get_object_info'). Also gives an exclusion ('Only the current scene is searched, so results match what the user is looking at'), and the re-call-not-cache guidance. This is textbook routing guidance.

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

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

Annotations cover read-only/idempotent safety, and the description goes well beyond them: the listing is uncapped and unpaged, no preset is parsed, MPFB caches the list per Blender session, refresh forces a rescan, and exists:false signals a cached entry whose file is gone. It also warns that hand-saved names can be listed here but refused by the two consuming tools.

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

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

Front-loaded and scannable, with the primary purpose and refresh rule up top. The bulleted enumeration of result fields is largely redundant given an output schema exists, though parts of it (size_bytes/modified come from os.stat, not MPFB) add genuine semantics.

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, read-only listing tool this leaves nothing an agent needs unresolved: it explains scope, handle semantics, cache/refresh behavior, failure signaling (listing_failed), and empty-result disambiguation via config_dir_exists.

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

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

Schema coverage is 0% (refresh has no description in the schema), so the description carries the full burden and does: refresh=true rescans the directory through MPFB rather than reading the cache, plus when it is and is not necessary. That is more meaning than a single boolean's schema could convey.

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

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

States a specific verb and resource ('List the character presets saved in MPFB's user config directory') and disambiguates scope by noting these are MPFB's 'save files', the same set its own preset panel offers. It also distinguishes itself from the surrounding list_* siblings by being uncapped and unpaged.

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?

Names the downstream consumers explicitly (mpfb_save_preset, mpfb_create_human_from_preset) and clarifies neither takes a path, so the returned name is the usable handle. It then gives a conditional rule for refresh ('the cache is rebuilt only when a preset is saved... but you do not need to pass refresh to find that out'), which is exactly the when/when-not guidance an agent needs.

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

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

Annotations already cover read-only/idempotent/no-op safety, and the description adds substantial context beyond them: session-lifetime caching, the weight fallback table (weights_from differing from name), that Rigify rigs are listed but raise on add when unavailable, and that unrecognized files are dropped silently. None of this contradicts 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?

The essential identifier/add_function warning is bolded and front-loaded, but the lengthy enumerated 'result carries' section largely restates return fields that the output schema already documents. Some detail earns its place; a meaningful portion is verbose duplication.

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

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

Given a single optional parameter and an existing output schema, the description is thorough — covering identifiers, refresh, availability, weights, and the deliberate mismatch with mpfb_get_object_info. The only shortfall is that the return-field documentation partly duplicates the output schema rather than adding new information.

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

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

Schema coverage is 0% for the single `refresh` parameter, so the description must compensate — and it does: it specifies that refresh rescans user data directories first, and explains the caching consequence that otherwise leaves a newly installed rig invisible.

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 — listing every rig addable to a MakeHuman basemesh — and scopes it into named categories (bundled standard/Rigify, custom). It also implicitly differentiates from siblings like mpfb_add_rig and mpfb_get_object_info by explaining what each returns.

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

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

Gives clear context for use and names the consuming sibling, warning to pass an `identifier` rather than a `name` to `mpfb_add_rig`, and explains when to set `refresh=true` (a rig installed after Blender started). It lacks an explicit when-not-to-use statement, so it stops 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 readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: results are capped ('check truncated'), total_count semantics, per-call scanning that sees targets installed since Blender started, and the meaning of listed_in_mpfb_ui:false. These are real operational traits an agent could not infer from annotations.

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

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

Front-loaded with the core purpose and the naming rule, and most sentences carry operational weight. However, the lengthy enumeration of result fields is partly redundant given an output schema exists, so it is longer than strictly necessary even though it is well-organized.

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 four-param read tool with an output schema and full annotations, the description covers everything an agent needs: what it returns, the truncation trap, the critical name-vs-shapekey_name rule (including the >60-char silent-failure case), and the unindexed-directory caveat. Nothing material 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 0%, so the description must carry the load and it does: section (exact, case-insensitive match against target.json or synthesized user dir; omit for overview), name_contains (substring applied to category and target names alike), limit (default 200, max 1000) and offset (paging over categories or user_targets). All four undocumented params are fully explained.

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 ('Find the MakeHuman modeling targets available in this Blender') and further scopes it ('named morphs like nose-scale-depth-incr that shape a character'). It explicitly excludes the phenotype attributes and routes them to mpfb_get_macro_details / mpfb_set_macro_details, so the agent can distinguish it from siblings without opening schemas.

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

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

Gives a clear when-to-use framing plus an explicit exclusion ('the phenotype ... is not here') and names the alternative tools for that case, and notes the relationship to mpfb_set_targets' modifiers entries. It stops short of contrasting with mpfb_get_target_stack (applied targets) or listing prerequisites, so not fully 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 readOnly/idempotent/non-destructive/openWorld, but the description adds non-obvious behavior: it fetches nothing itself, it still answers when MPFB or Blender is unreachable, source_of_truth/fallback_reason semantics are explained, and neither fallback is an error. It also states there is no pagination or truncation. This is rich context beyond the annotations.

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

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

Well front-loaded (purpose, then when-to-use, then fallback behavior, then result shape) with bullets that aid scanning. However, the long 'result carries' section restates much of what the output schema already provides, so it is somewhat heavier than needed for a no-arg tool.

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

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

For a trivial no-arg read tool with a full output schema and clear annotations, the description covers usage, fallback/edge-case behavior, and result contents. Nothing an agent needs in order to call it or 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?

Zero parameters, so the baseline is 4. The description's field-level detail is about the return payload rather than input semantics, so nothing here lowers the score; there are simply no parameters to clarify.

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 hands back addresses for the MPFB/MakeHuman community sites, enumerates what those links cover (downloads, asset packs, docs, forum, issues), and immediately distinguishes itself from the sibling list tools. An agent can tell it apart from mpfb_list_docs and mpfb_list_assets without opening any schema.

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

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

Explicit when-to-use (rather than composing a makehumancommunity.org address; when mpfb_list_assets comes up short or mpfb_get_status reports the system assets pack missing), plus a named alternative (mpfb_list_docs) for the developer-docs case. Both routing conditions and the exclusion are stated, not implied.

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

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

Annotations already declare the safety profile (readOnly=false, idempotent=true, destructive=true), and the description adds substantial context beyond them: the per-asset vertex-fit cost, idempotency semantics, the Rigify meta-rig-missing failure that never surfaces through MCP, and the ready:false / found:false / blocked_by error paths. No contradiction with the destructive or idempotent hints.

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

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

The definition is front-loaded and dense with useful detail, but it is long and spends a paragraph enumerating result fields that the output schema already carries. The Rigify caveat is verbose though genuinely informative, so minor trimming is possible.

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

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

For a complex, destructive, workflow-dependent operation the description covers purpose, sequencing, idempotency, and failure modes thoroughly, and an output schema exists for return values. The one real gap is the undocumented 'name' parameter, leaving the agent to infer how the target character is selected.

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

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

Schema description coverage is 0% and the single 'name' parameter is undocumented in both schema and description. The text discusses result fields (basemesh_name, rig_object_name) but never explains that the input 'name' selects the character, so it fails to compensate for the schema 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?

The description states a specific verb and resource ('Re-fit everything on a MakeHuman character to the current shape of its basemesh') and enumerates exactly what is refit: every mesh asset, the rig, and any sub-rigs. This distinguishes it clearly from siblings like mpfb_add_rig or mpfb_set_targets.

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 explicitly names the upstream tools that create the need (mpfb_set_macro_details, mpfb_set_targets, mpfb_symmetrize_targets with refit=false), describes the assets_possibly_stale signal, and advises batching modeling changes before one refit. This is explicit when-to-use guidance with named alternatives.

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, readOnlyHint=false, idempotentHint=false, so the destructive nature is known. The description goes far beyond by detailing exactly what is destroyed (object, mesh data), what is left behind (vertex groups, orphaned mesh data), the no-undo-across-socket warning, and the refusal conditions. This is rich behavioral context that greatly assists correct invocation.

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

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

The description is well-structured with clear sections (usage, parameter, return, refusals) and front-loads the key point. However, it is somewhat lengthy and could be trimmed slightly, but every sentence earns its place by providing crucial behavioral or parameter details.

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 destructive operation with a single parameter and rich output schema, the description covers all necessary aspects: purpose, alternatives, parameter semantics, return values (even though output schema exists, it explains the fields' provenance), failure modes, and side effects. It is complete for an agent to call correctly and interpret results.

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

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

Schema coverage is 0% (no description for the 'name' parameter in schema), so the description must compensate. It does: it explains that 'name' is the asset object's own Blender name, gives examples from mpfb_list_objects and mpfb_add_asset, warns about duplicate naming (hat vs. hat.001), and emphasizes it's required with no fallback. This adds significant meaning beyond the schema's bare type. A minor deduction because the description doesn't specify the exact format for names when duplicates exist (e.g., whether to use the exact name with suffix), but the guidance is strong.

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

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

Specific verb+resource: removing a mesh asset (garment, body part, or body proxy) from a MakeHuman character with proper cleanup. The description explicitly differentiates from generic deletion and implicitly from the sibling mpfb_add_asset (its counterpart), so an agent can distinguish it without opening the schema.

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

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

Explicitly states when to use this tool rather than deleting the object, and explains why (mask modifiers, sub-rigs, character holes). It also mentions the refusals that indicate when the tool won't work (subject_not_found, not_a_mesh_asset, etc.), providing thorough usage context.

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 and readOnlyHint=false; the description adds context beyond them: the write targets a file outside the .blend, nothing in Blender can undo it, the character itself is unchanged, the directory is shared with asset packs, and `name_shadowed` can hide a file permanently. This is exactly the deeper behavioral context the annotations don't carry.

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

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

Front-loaded with purpose and the irreversible-write warning, then naming rules, then side effects. Dense but nearly every sentence earns its place; the parenthetical error-code detail is heavy but useful. Slightly verbose overall.

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

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

An output schema exists, yet the description still helpfully notes what `result` carries (`path`, `fragment`, `face_units`, `metadata`, `overwrote`, `panel_synced`, `apply_with`). Combined with refusal handling and metadata semantics, it is complete for a destructive 9-param file-writing 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?

With 0% schema coverage the description must carry the load, and it does: naming rules for `expression_name`, `overwrite` default and behavior, and the metadata fields (`license` default "CC0", stored as given). However the schema also exposes a `name` parameter that the description never mentions, leaving one of nine params unexplained.

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

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

States a specific verb+resource (save a live face as a named expression file) with precise scope ('every non-zero ARKit face unit'). It explicitly distinguishes itself from `mpfb_apply_expressions` and presets, so an agent can route correctly without opening schemas.

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

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

Names the alternative (`mpfb_apply_expressions` with `mode: "replace"` at 1.0) and explains exactly why replace-vs-merge matters, plus when `overwrite` is needed. Refusal conditions (`name_shadowed`, `empty_expression`, `subject_not_found`) act as explicit when-not guidance.

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

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

Annotations already flag destructiveHint=true / readOnlyHint=false, but the description goes well beyond: it warns the write lands outside the .blend and is un-undoable, explains the overwrite gate and blocked_by/file_before semantics, and documents the Rigify meta-rig substitution that surprises users on round-trip. That is substantive disclosure beyond the structured hints.

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

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

Front-loads the critical warning (external, un-undoable write) before mechanics, and each paragraph is dense and purposeful. It is nonetheless very long and re-enumerates the entire `result` field set, some of which overlaps the output schema rather than adding new 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?

For a destructive, non-idempotent write with 0% schema description coverage, the description is remarkably complete: side effects, overwrite behavior, all refusal reasons, and the Rigify caveat are all covered. It even explains response fields beyond what the output schema alone would convey.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does for `preset_name` (name-not-path rule, allowed charset, 64-char cap, no leading dot) and `overwrite` (default false, destructive consequence). It does not explain the `name` property in the schema, and references `basemesh_name` which is not actually a parameter, leaving a minor mismatch/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 ('Save a character as an MPFB preset') plus the exact bundle of what gets serialized (phenotype, targets, rig, bodyparts, garments, materials), and names the consuming sibling `mpfb_create_human_from_preset`. An agent can distinguish this from sibling list/save tools without opening a schema.

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

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

Routes explicitly: this preset is what `mpfb_create_human_from_preset` (or MPFB's own panel) rebuilds, and overwrite=false is framed as the gate protecting an existing file. It also enumerates the refusal conditions (`subject_not_found`, `preset_exists`, `not_a_human_project`, etc.), giving clear when-it-will-and-won't-work guidance.

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

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

Annotations only declare destructive/non-idempotent; the description adds far more: the result is always a MakeSkin material named `makeskinmaterial`, slots are popped rather than deleted so old node groups survive, viewport colour derives from a per-type table, and the specific `blocked_by` refusal codes. It also discloses the `materials_destroyed` consequence of the required `name` and the absence of an active-object fallback.

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?

Purpose is front-loaded and the paragraphs map cleanly to mode selection, quirk disclosure, and refusals. It is dense rather than rambling, but the enumeration of result fields (`asset_object_name`, `object_type`, `path_resolved_by`, etc.) is partly redundant given an output schema exists, and could be trimmed.

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 destructive, mode-switching tool with zero schema coverage and unusual upstream quirks, the description covers sourcing, exclusivity, side effects, and failure taxonomy. Nothing an agent needs to call it correctly is missing, and the duplicated result-field list is harmless surplus rather than a gap.

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

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

Schema coverage is 0%, so the description carries the full burden and does: `name` is described as the asset's own Blender object name (sourced from mpfb_list_objects or mpfb_add_asset's `asset_object_name`, never the character), `path`/`fragment` are given a source and an XOR rule, and `restore_default` is given its default and its incompatibility. All four parameters gain semantics absent from 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?

First sentence states a precise verb+resource+scope: replace an equipped MHCLO asset's material with a shipped alternative, or restore the asset's own material. It explicitly names where the material data lives (mpfb_list_asset_materials, not mpfb_list_assets) and routes skin-bearing types to mpfb_set_skin, so an agent can separate it from every 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?

Gives explicit mutually-exclusive modes: either `path` or `fragment`, never both; `restore_default` cannot be combined with either. It names the only catalogue for path/fragment and states the signs under which the tool refuses (Basemesh/Proxymeshes/Skeleton), pointing to mpfb_set_skin as the alternative. Exclusions are stated, not implied.

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

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

Annotations cover the safety profile (destructiveHint=true, idempotentHint=true), and the description goes well beyond them: all-or-nothing validation before any write, refusal when the asset pack is missing, merge-vs-replace zeroing semantics, refit defaulting to true, and the transient nature of a composed face relative to the expression stack. This is unusually rich behavioral disclosure for a mutation 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?

It is long, but it is front-loaded with the action and the 'send the whole expression as one call' instruction, and each bolded paragraph covers a distinct concern (vocabulary, validation, mode, refit, transience, result fields). Nearly every sentence earns its place, though the result-field inventory is dense enough that it slightly overshoots what an agent needs up front.

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

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

An output schema exists, yet the description still clarifies the ambiguous result fields (`matches_stack`, `unexplained_face_units`, `removed_by_replace`) and explicitly frames non-error answers (`found: false`, `ready: false`). For a 4-param mutation tool with 0% schema coverage and multiple interacting modes, nothing material 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 0%, so the description carries the burden and largely does: `mode` merge/replace semantics and default, `refit` meaning and non-standard default, and the `{face_unit, value}` shape with `value` in 0.0-1.0. The `name` parameter is only obliquely referenced via 'a subject that cannot be resolved', leaving its role as the target subject implicit rather than stated.

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 ('Compose a MakeHuman character's face from ARKit face units') and immediately fixes the vocabulary and the target ('!ex-' shape keys). It explicitly distinguishes itself from the sibling reader `mpfb_get_face_units` and from the stack-based `mpfb_apply_expressions`, so an agent can route correctly without opening any schema.

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

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

Gives explicit when-to-use guidance ('Send the whole expression as one call', call `mpfb_get_face_units` first for legal names) and explicit alternatives ('`mpfb_save_expression` keeps a composed face', while `mpfb_apply_expressions` and preset loads discard composed work). It also states the precondition that the `faceunits01` pack must be installed.

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

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

Adds substantial context beyond the annotations: omitted sliders are left alone, race weights are independent and not normalized (default sums to 0.99), prune/refit defaults and their rationale, plus the blocked/not-found/empty-call answer-rather-than-fail cases. This is far more than the annotations' readOnly/destructive/idempotent hints.

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?

Long, but front-loaded and organized with bold lead-ins so each block is scannable. Some content, notably the enumeration of result fields, is arguably redundant given an output schema exists, but the length is largely justified by 14 undocumented parameters.

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?

Comprehensive for a mutation tool with 14 params: covers ranges, defaults, non-obvious semantics, side effects, and failure modes. It goes beyond the minimum by detailing return fields, though those are already in the output 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 0%, so the description carries the burden and does so well for the hard cases: 0.0-1.0 ranges, 0.5 neutral vs 0.33 for race weights, age/gender scales, race-weight independence, and prune/refit defaults. It is weaker on the generic sliders (height, muscle, weight, cupsize, firmness, proportions) and on name, which are only covered by the blanket 'sliders' statement.

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 macro details / phenotype sliders, rebuild the shape) and immediately names the read counterpart mpfb_get_macro_details. An agent can distinguish it from sibling setters without opening any schema.

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

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

Explicitly prescribes the workflow: read with mpfb_get_macro_details, then pass only what should differ. It also gives when-to-use guidance for refit (leave false, call mpfb_refit_human once after a series of changes) and names the alternative sibling, so selection is unambiguous.

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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description goes well beyond that with all-or-nothing atomicity ('Nothing is written unless every entry resolves'), the scene-linear RGBA vs sRGB color gotcha, the fact that linked sockets are unwritable and how write_instead names a substitute, and the cross-object side effect via materials_written.

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

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

Front-loads the verb and scope, then uses bullets for the three section shapes and bolded callouts for the atomicity and color-space rules. Dense and long, but nearly every sentence conveys a constraint an agent needs; the layered-skin paragraph is the only portion bordering on overload.

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 rich side effects, it covers atomicity, color encoding, resolution failure modes, linked sockets, and cross-object material sharing. An output schema exists (so return values are not strictly required), yet the description's result/materials_written explanation still adds useful behavioral context.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it does define the entry shapes for eyes, skin, and color_adjustments ({socket|group|object_name, value|color}) plus the value-vs-color mutual exclusion. The 'name' parameter is never explained in either schema or description, leaving one 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 (change) plus the exact resource (MakeHuman character's procedural material settings) and enumerates the affected areas (iris colours, layered skin, hair/garment tint). It also distinguishes itself from siblings by naming mpfb_set_skin and mpfb_set_asset_material as the tools that would overwrite these values.

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?

Tells the agent to source section/group/socket names from mpfb_get_material_settings and warns that re-adding eyes or calling mpfb_set_skin/mpfb_set_asset_material discards these settings, which is clear routing context. It stops short of an explicit 'use this instead of X when Y' rule, but the prerequisite read and the destruction warning give strong guidance.

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

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

Far exceeds the annotations, which only flag destructiveHint/idempotentHint=false. The description spells out exactly what is destroyed (all materials on basemesh and body proxy, node groups included), that there is no undo across the socket, that material_instances is force-disabled for LAYERED/GAMEENGINE/MAKESKIN, and enumerates every refusal path and its blocked_by value.

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

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

The single most important fact - that all materials are destroyed with no undo - is bolded and front-loaded, and each subsequent paragraph covers a distinct concern (input selection, skin_type, instances, outputs, refusals). It is dense and long, but nearly every sentence adds actionable detail 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?

For a destructive, multi-mode tool it covers the full contract: inputs, the five material trees, instance-inclusion rules, output fields (including scale_assumption and settings_file_created), and every refusal case. Even though an output schema exists, the description supplies the interpretation an agent needs to act on the results.

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 0% schema coverage and 5 params, the description carries the full burden and delivers: mutual exclusivity of path/fragment, basename resolution semantics, the five skin_type values and what each builds, the counter-intuitive MAKESKIN default, and material_instances' forced-off behavior. Only the 'name' parameter is left largely implicit, but the surrounding context makes its role clear.

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 ('Give a MakeHuman character a skin') and immediately anchors it to MPFB's own skin library panel behavior. The dual target (basemesh plus body proxy) is made explicit, so an agent can distinguish it from set_material_settings or set_asset_material without reading further.

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?

Extensive when-to-use guidance for parameters: path vs fragment vs neither, and which condition selects each skin_type. It points to mpfb_list_assets to obtain fragments. However, it never explicitly distinguishes this tool from sibling tools like mpfb_set_asset_material or mpfb_set_material_settings, so the tool-selection case is inferred 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 flag destructiveHint=true and idempotentHint=true, but the description adds substantial context beyond them: all-or-nothing resolution ('Nothing is applied unless everything resolves... zero changes are made'), that prune deletes a shape key at zero, that symmetry can touch up to four shape keys, and the silent-failure trap when a filename over 60 chars is used instead of shapekey_name. This is genuine behavioral disclosure.

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

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

Long, but front-loaded with the core distinction and organized with bold leads and bullets so key rules are scannable. Most content earns its place given the complexity, though the output-shape paragraph could be trimmed since an output schema exists.

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

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

For a batch mutation tool with 0% schema coverage and opaque nested params, the description supplies the entry shapes, ranges, side rules, failure semantics, default behaviors (symmetry/prune/refit), and the shapekey_name-vs-filename trap. Only the undocumented 'name' parameter keeps it from being airtight, but the coverage is otherwise thorough.

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

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

Schema coverage is 0% and nested objects are opaque (additionalProperties: true), so the description carries the full burden and does so well: it defines modifiers entries as {section, category, value, side} with value ranges (-1.0..+1.0 with opposites, 0.0..1.0 without) and side requirements, and targets entries as {shapekey_name, value} in 0.0..1.0. The one gap is the top-level 'name' parameter, which is never explained.

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 ('Change a MakeHuman character's modeling targets') and immediately distinguishes two operating modes (modifiers vs targets) with different roles. It names the sibling mpfb_list_targets as the source of section/category/shapekey_name values, so an agent can tell this apart from the listing 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?

Explicitly says which mode to use normally ('modifiers is the level to use normally') and when to reach for the alternative ('targets is the escape hatch, for a user-installed target that belongs to no category'). It also gives conditional guidance on refit ('leave it false, read assets_possibly_stale, and call mpfb_refit_human once when the modeling is done') and on batching ('Send the whole change as one call').

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

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

The description goes far beyond the annotations. While annotations correctly flag it as destructive and not idempotent (ambiguous), the description adds critical context: there is no undo, dry_run produces a preview that writes nothing, prune/refit behavior, how `skipped` is handled (does not abandon the whole operation), and that certain failure conditions are answers, not errors. This is exemplary behavioral disclosure.

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

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

The description is dense and well-structured with bolded parameter names and logical paragraph breaks. Every sentence adds value, though it is quite long. It is front-loaded with the core purpose and critical warnings.

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

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

Given the tool's complexity (destructive, no undo, multiple parameters, dependent on external state), the description covers all necessary aspects: purpose, prerequisites, parameter semantics, destructive nature, dry-run workflow, and output interpretation. It even references the output schema's fields to explain their meaning.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains why `direction` is required (cannot guess), what `section` restricts, what `prune` and `refit` do, and the effect of `dry_run` on the `targets` output. It compensates completely for the lack of schema descriptions.

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 ('Make a MakeHuman character's modeling targets left/right symmetric') and immediately differentiates itself from MPFB's own symmetry feature and from mpfb_set_targets. It precisely explains the scope (modeling targets) and mechanism (copying one side onto the other).

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

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

Explicitly names the prerequisite sibling tool (mpfb_get_target_stack) to call first and why (its `asymmetries` field). It directs the agent to use dry_run first and explains when to use `section`. This is a strong example of explicit when/when-not guidance.

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