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

Goes well beyond the destructiveHint/readOnlyHint annotations by disclosing that a NEW .casc copy is written first and that this changes scene identity, the exact-hash prerequisite for overwriting, scope rejection, and timeout recovery behavior (read files back). These are non-obvious side effects an agent must know before calling.

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 and front-loaded, with the identity-changing side effect stated early. The telegraphic fragments ('ASCII, Y-up, Euler filter') pack information efficiently, though the staccato style slightly reduces readability.

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

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

For a 6-param nested-schema mutation tool with no output schema, the description covers the destructive copy step, overwrite protection, scope limits, and timeout handling. Return-value details are the only notable omission, and no output schema exists to cover them.

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 the non-obvious parameters: expected_sha256 for replacement, source_copy_path implied by the new .casc copy, and the frame-range restriction tied to options. It does not add syntax notes for scene_id/character_id, but those are self-evident identifiers.

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 (Export) plus resource and scope (complete single-character scene, baked skeleton/mesh/animation, native FbxLoader). It is the only export tool among the siblings, and the descriptor makes that unambiguous.

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

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

Gives real usage conditions: full stored frame range only, new FBX by default vs. replacement requiring expected_sha256, and rejection of unsupported scopes. It does not point to the sibling get_fbx_export_status for polling status, so the alternative path 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 already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context: it reads the actual loaded host rather than a cached/static source, and it explicitly does not evaluate runtime rig or license preconditions. That caveat is meaningful for an agent deciding whether to rely on the output.

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

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

One compact sentence with two informative clauses and no filler. The informational caveat is placed after the main action, which is reasonable, though the leading phrase is less clear than it could be.

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

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

With no output schema, the description should convey what the returned capability/contract data looks like, but it does not. For a zero-parameter read tool whose entire value is the returned content, the definition leaves the agent unable to anticipate the result format or content scope.

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

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

The tool takes zero parameters, so there is nothing for the description to explain beyond the schema. Baseline 4 applies.

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

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

The description names a read action and a source ('actual loaded host'), but 'contracts' is domain jargon that does not clearly map to bridge capabilities, and it draws no distinction from siblings such as get_rig_semantics or ping_cascadeur. The purpose is discernible but vague.

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

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

There is no when-to-use guidance, no when-not-to-use guidance, and no named alternative. The clause about unevaluated preconditions is a caveat, not usage direction, so an agent still cannot tell when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral guarantee beyond the annotations: the returned data shape is accepted by set_character_pose, which prevents an agent from inventing a conversion step. It omits any note on return size or frame-range semantics.

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

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

Two tight sentences, front-loaded with the resource and scope, followed by the actionable round-trip fact. No filler or restated schema content.

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

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

For a read-only, two-parameter tool with no output schema, the description conveys what comes back (all joint local/global transforms and Point targets) and how it can be reused. Only the meaning of the 'frame' parameter and any size/format characteristics of the payload are left unaddressed.

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

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

Schema description coverage is 0% and neither parameter is explained in the description. Nothing says what 'frame' means (frame index vs. time), what the 0-120 bound represents, or that character_id is a UUID, so the description does not 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?

States a specific verb (read) and resource (every character joint local/global transform plus all native Point targets), and the 'in ONE call' phrasing distinguishes this batch read from single-target siblings like get_local_transform or get_transform. It also names its write counterpart, set_character_pose, pinning down its role in the API.

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 round-trip statement ('Returned pose is writable by set_character_pose') tells the agent exactly when this tool pairs with a mutation, and the batch framing implies use over get_local_transform/get_global_transform when the whole pose is needed. There is no explicit exclusion clause, so it falls short of a 5.

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

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

Annotations already declare this is a non-destructive, read-only, closed-world operation. The description adds useful scope by listing what the read returns, but it does not disclose pagination, error behavior, or output format details beyond that list.

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 a single front-loaded sentence with no redundant wording. Every phrase earns its place by specifying the read scope and the identifying input.

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

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

For a one-parameter read tool with no output schema and annotations covering safety, the description is nearly complete: it states what is read and by what identifier. It falls short only in not clarifying when this skeleton read is preferable to related sibling tools.

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 semantic burden. It does identify the single parameter as a character UUID, which maps clearly to character_id, but it adds little beyond what the schema's UUID pattern already implies.

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

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

The description uses a specific verb, 'Read', and names the exact resource returned: full native joint hierarchy, rig controls, bindings, constraint references, and shared tracks. It is clearly distinguishable from sibling tools such as get_character_pose or get_rig_semantics because it targets the complete skeleton data by character UUID.

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

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

The description provides no explicit guidance on when to use this tool instead of alternatives. It implies usage through the verb and resource, but it does not say when-not to use it or point to siblings like get_rig_semantics or get_character_pose for related 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 declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds the useful detail that the response includes the available animation frame count, but nothing about return format or error behavior.

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

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

A single, front-loaded sentence with no filler. Every word earns its place, and the read intent precedes the secondary return detail.

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

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

With no output schema, the description must hint at return values, and it does so by naming both the current frame and the animation frame count. For a trivial zero-parameter getter this is nearly complete, missing only the exact frame-range semantics.

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

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

The tool takes zero parameters, so there is no parameter semantics to document. The baseline of 4 applies since no schema compensation is needed.

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

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

States a specific verb ('Read') and resource ('current frame'), plus the additional return of the animation frame count. This cleanly separates it from the sibling set_current_frame, though it does not name that sibling explicitly.

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

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

Usage is only implied: an agent can infer this is the query counterpart to set_current_frame for checking playback position. There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description correctly reinforces with "No export or file writes." It adds real value beyond the annotations with "Method availability is not proof of a successful export," which warns the agent how to interpret a positive result. It stops short of describing the shape of the returned entitlement data.

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

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

Three short sentences, each earning its place: purpose, non-mutating guarantee, and an interpretation caveat. The core purpose is front-loaded with no filler or repetition of the name.

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

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

With no output schema, the description still names what is returned (entitlement and loader methods) and warns about interpreting that result, which covers the essential contract for this query tool. Return structure/format remains unspecified, but nothing critical to invoking 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter-related gaps exist.

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

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

Specific verb ("Read") plus a concrete resource ("current native FBX export entitlement and loader methods"), so the agent knows this is a capability/status query rather than an action. It only implicitly contrasts with the sibling export_fbx via "No export or file writes," so a 4 rather than a 5.

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

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

"No export or file writes" implies this is the pre-flight check to run instead of export_fbx when you only want to know whether exporting is possible. However, it never states when to call it versus export_fbx or get_bridge_capabilities, and there is no explicit when-not guidance, leaving usage inferred.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful nuance that the returned coordinates are evaluated world-space values with a default-to-current-frame behavior, but does not discuss frame-scoped evaluation semantics or what happens for invalid frames.

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

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

A single front-loaded sentence with no filler, though the telegraphic phrasing ('at frame, default current') reads more like a note than a definition and slightly obscures the default-frame 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?

Since there is no output schema, the description must imply the return shape, and 'position/quaternion' does that minimally. It leaves gaps around identifier format, frame bounds handling, and how the result relates to keyframed vs evaluated transforms.

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

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

Schema coverage is 0%, so the description carries the burden, and it does document that 'frame' is optional and defaults to the current frame — information absent from the schema's min/max bounds. However, it never clarifies the 'object' parameter's expected identifier form even though it is the only required parameter.

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

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

States a specific verb ('Read') and resource ('actual world position/quaternion'), and the word 'world' implicitly distinguishes it from get_local_transform among the siblings. It stops short of naming the sibling it differs from, so an agent must still infer the local-vs-world split.

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

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

The only usage information is that frame defaults to current. There is no statement of when to prefer this over get_local_transform, get_transform, or get_pose, all of which sit in the same sibling cluster.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the returned data is local rotations plus 'verified hierarchy bindings' and that body hand Points do not drive finger shape. It still says nothing about scope needing a specific character state or frame validity.

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

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

A single well-formed sentence that front-loads the verb and resource. Dense with domain jargon but no wasted words.

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?

As a read-only getter with no output schema, the description usefully sketches the returned content (finger rotations, hierarchy bindings). However, with two required parameters and zero schema description coverage, the definition is incomplete about how to supply inputs.

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

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

Schema description coverage is 0% and the description never mentions character_id or frame. The frame's 0-120 bound and the UUID pattern for character_id are left entirely to the raw schema, so the description adds no parameter meaning.

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

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

States a specific verb (Read) plus a precise resource (Cascy finger local rotations and verified hierarchy bindings), which separates it from generic pose getters like get_pose and get_character_pose. The scope is clearly finger-focused, though 'Cascy' is jargon an agent must already know.

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

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

No statement of when to use this versus the many sibling pose readers (get_pose, get_character_pose, get_semantic_pose) or the setter set_hand_pose_sequence. The caveat about body hand Points is a data note, not routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds one meaningful behavioral nuance, 'actual', suggesting it reads the evaluated current value rather than a keyframed/declared transform, but does not elaborate on that distinction.

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

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

A single compact sentence with the essential scope front-loaded. It is efficient, though arguably terse enough to be cryptic for an unfamiliar agent.

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

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

For a simple read-only getter with annotations covering safety, the description conveys what is returned (position/quaternion) and the coordinate space, and there is no output schema to explain. It still leaves gaps around the required 'object' argument and the meaning of 'actual', so it is adequate but not complete.

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

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

Schema coverage is 0%, so the description must compensate, and it only partially does: it clarifies that 'frame' defaults to the current frame, but says nothing about the required 'object' parameter (format, expected identifier) beyond the name.

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

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

States a specific verb ('Read') and a precisely scoped resource ('actual parent-relative position/quaternion'), which implicitly distinguishes it from siblings like get_transform and get_global_transform by naming the coordinate space. It never names those siblings explicitly, so the differentiation is inferential rather than stated.

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?

'default current' gives useful calling context for the frame parameter, implying the tool is used to inspect a pose at a given or current time. However, it offers no guidance on when to prefer this over get_transform, get_global_transform, or get_pose, so usage must be inferred.

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

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

Annotations already declare readOnlyHint=true, non-destructive, closed-world, so the safety profile is covered. Beyond that, the description adds a genuinely useful behavioral caveat: names are not unique IDs, which prevents an agent from misusing the returned values as keys. That is non-obvious context not present in the annotations.

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

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

A single tight sentence with the key caveat front-loaded; nothing wasted.

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

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

For a two-parameter read tool with no output schema, the description conveys the resource and the name-uniqueness caveat but omits pagination mechanics (defaults, max page size, iteration), which is the main operational detail an agent 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 description coverage is 0% for both limit and offset; the schema gives only types, defaults and bounds. The description alludes to a 'bounded page', which hints at limit/offset semantics but adds no explanation of paging behavior, defaults, or how to iterate. With low coverage, the description should compensate more than it does.

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

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

States a specific verb (read) and resource (object names and types) with a scoping qualifier ('bounded page'). It does not, however, distinguish itself from siblings like list_characters or get_scene_info, so an agent must infer the domain from the name alone.

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

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

There is no guidance on when to use this instead of related listing tools, nor any preconditions. The word 'bounded' implies pagination is expected but does not say when to prefer this over other enumerations.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond those annotations: it is a single round-trip and explicitly does not move the playhead, which is important for an animation-tool read operation.

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

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

Two sentences, front-loaded with the core operation and followed by key behavioral constraints. There is no filler, and the most important information for selecting the tool comes first.

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

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

For a three-parameter read tool with no output schema and 0% schema description coverage, the description covers the two main modes and the no-playhead behavior. It remains incomplete because the required frame parameter is unexplained and return-value details are only partially described.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It maps 'objects' to an explicit object list and 'root' to all joints under a root, but the required 'frame' parameter is never explained, and no format or constraint details are added for any parameter.

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 read operation ('Read an explicit object list ... OR all real Joints under root') and names the returned content ('parents and local/global transforms'). It does not, however, distinguish itself from nearby siblings such as get_character_pose, get_semantic_pose, get_hand_pose, or get_transform.

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 describes two input modes ('explicit object list' vs 'all real Joints under root'), which implies when each parameter set is appropriate. But it gives no explicit when-to-use guidance against alternative pose/transform retrieval tools, and no exclusions or prerequisites.

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

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

Annotations already declare readOnly/non-destructive, so the safety profile is covered. The description adds value beyond them by disclosing failure behavior (refuses ambiguous names or unsupported topology) and a domain constraint (driven joints are read-only).

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

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

Two dense sentences, front-loaded with capability then constraints; nothing is padded. Jargon like 'Cascy v1' and 'topology fingerprint' is unexplained but does not waste 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?

It names the categories of information returned, which partially compensates for the missing output schema, and covers error/refusal behavior. However it never ties the operation to character_id or explains what the 'validation' result looks like.

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 required character_id parameter is never mentioned in the description, so no semantics, scope, or format guidance is added. The parameter is only self-explanatory from its name.

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

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

States a specific verb pair (discover/validate) and concrete resources: role groups, native Point UUIDs, rig bindings, topology fingerprint. The domain is clearly distinct from pose/transform siblings, though no sibling is named for contrast.

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

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

No guidance on when to call this versus get_semantic_pose, get_character_skeleton or other discovery tools. An agent must infer that this is a prerequisite lookup step rather than a pose operation.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false and a closed-world scope, so safety is covered. The description adds real value by enumerating the returned fields (name, frame, object count), which matters because there is no output schema to otherwise reveal the return shape.

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

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

A single front-loaded sentence with no filler; every word (verb, resource, three returned fields) earns its place.

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

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

For a trivial no-arg read with full annotation coverage, the description is essentially complete: it says what is read and what comes back. Only the absence of sibling routing keeps it from being fully complete.

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

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

Zero parameters and an empty object schema, so there is nothing to disambiguate; the baseline for a no-parameter tool applies.

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

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

States a specific verb ('Read') and resource (Cascadeur scene info) and enumerates exactly what is returned: name, frame, object count. This distinguishes it by content from siblings like get_objects and get_current_frame, though it never names those alternatives explicitly.

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

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

No guidance on when to use this versus the overlapping sibling tools (get_objects, get_current_frame, get_bridge_capabilities). The agent must infer that this is a lightweight summary call rather than a targeted query.

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, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely useful context beyond annotations: it states that full rig validation always runs, that defaults return all 11 roles plus joint states, and that partial reads skip animation/whole-body validation. No contradiction with 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?

Four compact sentences, front-loaded with what is read and the units, then defaults and toggles. No filler, though the last sentence could be folded into the defaults discussion.

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

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

There is no output schema, and while the description indicates what is returned conceptually (named Point targets in world units, joint states), it doesn't describe response shape, ordering, or error modes. Given a 4-param read tool with 0% schema coverage, more return/param detail would help.

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 does explain the semantics of roles (1-11 unique semantic roles) and include_joint_state (false omits joint states), but frame and character_id get no coverage, and frame bounds (0-120) and the UUID pattern are only in the schema. Partial compensation.

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 named Point targets in world scene units') and clarifies units and scope. It is distinguishable from siblings like get_pose/get_character_pose by the 'named Point targets' and 'semantic roles' framing, though it never explicitly names an alternative to route between them.

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

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

Gives implied context (defaults to all 11 roles, optional role selection, joint-state toggle), but does not articulate when to prefer this over get_pose, get_character_pose, or get_rig_semantics. The final sentence hints at a caveat (partial reads don't validate animation) without stating an explicit when-to-use rule.

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

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false), yet the description adds real context: it does not move the playhead, does not cache a rig between requests, uses native stored values, and validates the rig before selecting values. These are genuine 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?

Three dense sentences with no filler, and the core batch-read constraint is front-loaded. The phrasing is compact but slightly overloaded mid-sentence ('Optional roles and include_joint_state select values after complete rig validation').

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

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

No output schema exists, so the description must convey return shape, and it only gestures at it ('native stored values'). It does cover non-side-effect behavior well, but an agent still lacks detail on what the response contains and how errors (invalid frames, non-existent frames) are surfaced.

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 it only partially compensates – it clarifies that frames are read in requested order and that roles/include_joint_state 'select values', but explains nothing about the role enum meanings, include_joint_state's default/effect, or character_id. It adds some meaning but leaves notable gaps.

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

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

States a specific verb (Read) and resource (semantic pose for 1-8 frames in one call), plus the batch scope that makes it distinct from a single-frame read. It does not name the single-frame sibling get_semantic_pose, so sibling differentiation is left implicit rather than stated.

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 batching constraint ('1-8 unique existing frames in ONE MCP call') implies when to prefer this over repeated single-frame calls, but there is no explicit when/when-not statement or named alternative among the many siblings (get_semantic_pose, get_pose, offset_semantic_pose_sequence).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description goes beyond them by specifying the returned data shape, including the non-obvious quaternion component ordering [w,x,y,z] and that distances are in scene units, which is genuinely useful behavioral detail for interpreting results.

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

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

A single dense sentence with the verb and payload front-loaded and no filler. It is efficient, though the list of returned fields is packed tightly enough that the frame-selection behavior is silently omitted.

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

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

With no output schema, the description correctly steps in to describe return values, but it stops short of explaining the frame parameter, its default, or what 'track key state' actually reports. For a two-parameter read tool this is adequate but has a clear gap.

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

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

Schema description coverage is 0%, so the description must carry the load. It clarifies 'object' as a 'unique object name', but the 'frame' parameter (0-10000) is never mentioned, leaving half the 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 ('Read') and enumerates exactly what is returned: world position in scene units, rotation quaternion with component order [w,x,y,z], and track key state. The 'world' qualifier implicitly separates it from get_local_transform, but it never names or contrasts with its closest siblings (get_global_transform, get_pose).

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

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

There is no when-to-use guidance, no statement of prerequisites, and no routing to alternatives such as get_local_transform or get_global_transform for non-world-space reads. The agent must infer selection criteria purely from the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral context beyond those annotations: it discloses the data types read, the frame limit (max 121), and explicitly states that the playhead is not moved. It does not cover return format or permission requirements, but with annotation coverage the bar is lower.

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

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

Two compact sentences, front-loaded with the action and data scope, followed by the key non-mutation guarantee. No filler or redundancy; every phrase earns its place.

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

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

Given no output schema, the description adequately enumerates the three categories of returned data (track curves, COM, connection errors) and the frame cap. The main missing piece is parameter guidance for character_id, which prevents a perfect score. Safety and read-only behavior are fully covered by annotations and the playhead note.

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

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

Schema description coverage is 0% for the single required parameter character_id. The description never mentions the parameter, its meaning, or how to obtain valid IDs. The schema supplies only a UUID pattern, leaving the description to compensate but it does not, so this is a significant 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 ('Read') and a precise set of resources (native track curves, rigid-body mass-weighted COM, rig connection errors) over a defined scope (every stored frame, max 121). It clearly distinguishes itself from pose-reading or transform tools by naming the exact inspection targets. However, it does not explicitly contrast itself with any sibling, which keeps it from a 5.

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

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

The only guidance is 'Does not move the playhead', which hints at a safe read operation but does not state when to use this tool versus alternatives like get_character_pose, get_rig_semantics, or retime_character_motion. There is no explicit when-to-use, when-not-to-use, or alternative routing despite many sibling tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds useful context that it returns actual RigInfo owner UUIDs and that names are display labels only, but does not detail return format or any other behavioral traits.

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

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

A single, front-loaded sentence that conveys the core action and a key clarification without any wasted words. It is appropriately sized for a simple 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?

Given the tool's simplicity, no parameters, and no output schema, the description is largely complete: it states what is listed and clarifies that UUIDs are returned. A minor gap is the absence of explicit mention of the return structure (e.g., an array of UUIDs), but the core information is present.

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

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

The tool takes zero parameters, so there are no parameter semantics to clarify. The baseline score for zero parameters is 4, and the description does not need to compensate for any schema gaps.

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 ('List') and resource ('RigInfo owner UUIDs') with clear scope ('in the saved scene'). It distinguishes the output from display names, but does not explicitly name a sibling tool as an alternative, so it falls short of the highest clarity tier.

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 offers no guidance on when to use this tool versus alternatives. It implies usage (to get character UUIDs), but lacks any explicit when/when-not statements or references to sibling 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 mark it destructive/non-readOnly, and the description adds substantial context beyond that: a single checked transaction with full-scene snapshot and rollback, creation of LINEAR intervals that discard authored easing, non-idempotent behavior, and the warning never to auto-retry after timeout. It also discloses return semantics (solved roles, not requested values) and explicit exclusions. This is exactly the extra behavioral load the annotations leave open.

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 most consequential facts (what it translates, and the mutation/transaction behavior) are front-loaded, and every sentence carries a distinct constraint or caveat. No filler.

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

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

For a destructive, nested, 4-parameter tool with no output schema, the description covers transaction safety, easing loss, idempotency, return semantics, and exclusions. An agent has everything needed to call it safely and interpret the result.

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 parameter meaning, and it does add real signal: offsets are world-space [dx,dy,dz] applied per named role, and frames must be 1-8 existing frames using their own current targets. It does not clarify scene_id/character_id formats or the full role vocabulary, which the schema only partially exposes through property names.

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

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

It states a precise verb and resource: translate every Point slot of each named role by its world-space [dx,dy,dz] across 1-8 frames. The scope (world-space, point slots, frame-bounded) separates it from generic transform siblings and from set_pose_sequence. An agent can identify the operation without opening the schema.

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

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

It gives operational guidance (not idempotent, never auto-retry after timeout, read back first) and implicitly routes away from the sibling offset_semantic_pose_sequence_preserving_curves by stating it does not preserve authored easing. It stops short of naming that alternative explicitly, so the when-to-use-vs-alternative handoff 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?

Goes well past the destructiveHint=true annotation by disclosing what is preserved (key layout, track membership, interpolation, easing weights, tangent metadata), what is written (only selected Point channels), what is validated (all-frame geometry, unedited FIXED/baked tracks), the non-idempotency, and the need to read back after timeout. This is a rich and accurate behavioral contract.

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 and constraint set into a single dense paragraph with essentially no filler; each clause carries a distinct rule or side effect. The density is justified by the tool's complexity, though the run-on structure slightly reduces scanability.

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, non-idempotent, no-output-schema mutation with several rejection paths, the description covers preservation guarantees, side effects on coupled rig Points/Joints, validation scope, and read-back guidance. Only the parameter-level details (offset units/space) remain unaddressed.

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

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

Schema coverage is 0%, so parameters are undocumented structurally; the description partly compensates by mapping 'role groups' to the offsets keys and '1-8 existing keys' to the frames array bounds, and by noting no key creation. It still leaves coordinate space, units, and the scene_id/character_id roles unexplained, so it only partially closes the 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 (Offset) and resource (named Point role groups at 1-8 existing keys on their tracks), plus the transaction scope ('one checked transaction'), which cleanly separates it from sibling offset_semantic_pose_sequence and set_pose_sequence. An agent can identify the operation without opening the schema.

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

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

Gives explicit when-not conditions: rejects editing FIXED tracks, custom tangents, additive stacks, cycles, or unavailable state, and excludes rotation, finger curling, and timeline extension. It does not name an alternative sibling for those excluded cases, which is the only gap.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds that this verifies a 'live response' from the host bridge, which is a meaningful behavioral note, but it says nothing about latency, failure modes, or retry expectations.

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

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

A single front-loaded sentence with no filler; every word contributes to identifying the tool's action and target.

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

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

For a parameterless connectivity tool with annotations covering the safety profile and no output schema, the description is nearly complete. The only minor gap is that it does not hint at what a successful confirmation looks like.

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 with 100% schema coverage, so the baseline is 4. There is nothing for the description to disambiguate about inputs.

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

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

States a specific verb (confirm) and resource (live response from the Cascadeur host bridge), which reads clearly as a connectivity/health check. It is distinguishable from siblings like get_bridge_capabilities, though the description never uses the word 'ping' or 'health check' to make the distinction fully explicit.

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

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

No guidance on when to call this versus alternatives, or prerequisites such as running it before other operations to verify the bridge is reachable. The purpose implies a connectivity check but the timing and conditions are left entirely to inference.

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

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

Goes well beyond the annotations by disclosing the exclusive-ownership lock, the rejection of edits while active, the 'never advances frames with a script' constraint, and the pending return that must be closed with stop_animation. It does not explain what state makes destructiveHint=true, which is the one gap for a mutation-flagged 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?

Four short sentences, front-loaded with the action and its main constraint, and every sentence carries information. The 'Timeline.Play' jargon is slightly dense 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?

There is no output schema, and the cryptic 'Returns pending' line does not tell the agent what a successful call yields or how to poll. Combined with fully undocumented parameters, the definition is serviceable for invocation but leaves real gaps for a stateful, lock-taking operation.

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

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

Schema description coverage is 0% and the description only implies a bounded range via 'bounded'; it never explains scene_id format, whether start_frame/end_frame are inclusive, why the maximum is 120, or the start/end relationship. With three undocumented required params, the description does not compensate for the coverage gap.

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

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

States a specific verb+resource ('Start a bounded native Timeline.Play observation') with scope ('on a stopped scene') and explicitly separates itself from the sibling stop_animation by naming it as the required follow-up. An agent can distinguish it from set_current_frame/set_keyframe 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 clear preconditions ('stopped scene', 'requires exclusive playback ownership', 'rejects edits while active') and routes to stop_animation for measurement. It stops short of an explicit when-not-to-use rule (e.g. use set_current_frame for single-frame scrubbing), so it is clear context without full alternatives coverage.

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

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

Annotations already declare destructiveHint=true and openWorldHint=false, so safety is partly covered; the description adds substantial beyond-schema behavior: identity/topology/key-layout guards, full readback, refusal of changed track structure and external scene edits, bounded native Undo with full-state verification, and joint verification before commit. These refusal/verification semantics are exactly the kind of context an agent needs before invoking a destructive restore.

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 verb and resource, which is good, but the body is telegraphic fragment-speak (semicolon-separated clauses, mode-hopping) rather than structured prose. Several clauses about guards could be compressed once and referenced, so the density is not fully earning its place.

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

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

For a 5-param, no-output-schema, destructive tool the description covers the important refusal and verification behavior, but it omits the meaning of snapshot_id and scene and does not state what a successful restore returns or how failures surface. Adequately informative on behavior, incomplete on the calling contract.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It does explain scene_id, character_id, and path for the durable variant, but never explains snapshot_id (the primary handle for the clip-snapshot mode) or the 'scene' parameter, leaving two of five parameters semantically opaque.

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

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

States a specific verb and resource ('Restore clip transforms from an opaque host-memory snapshot') and explicitly distinguishes itself from the sibling save_pose_snapshot's inverse operation and from a general scene undo. The three execution modes (clip snapshot, character/scene_id, durable path) are named, though the bundling makes the core purpose slightly harder to extract.

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?

Offers exclusions ('Not a general scene undo', 'Not a whole-clip backup') and conditional routing ('For character snapshots supply scene_id'), which is real guidance. However, the mode selection is tangled – it never clearly states when to use snapshot_id vs scene_id vs the durable path variant, so the agent must infer the mapping.

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 this as a destructive, non-read-only, closed-world write. The description adds substantial context beyond that: single checked transaction, automatic snapshot/rollback, preservation of solved Point poses, verification of all joint key states, and an explicit exclusion of arbitrary tangent vectors and AI interpolation.

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?

Compact and front-loaded with the decisive scope ('2-8 complete synchronized character keys... ONE checked transaction'). But it is telegraphic to the point of ambiguity — 'Read back after timeout' and 'Preserves solved Point poses' assume internal vocabulary an agent may not share, so density partly costs clarity.

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

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

For a destructive multi-key mutation with no output schema and no parameter descriptions, the description does cover transactionality, rollback, verification, and scope restrictions. It still leaves the meaning of stabilize_contacts and the failure/timeout behavior underspecified for an operation this consequential.

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, but it only gestures at the 'keys' payload (interpolation/easing weights, count limits) and leaves source, target, left_weight, right_weight, stabilize_contacts, and the id parameters entirely unexplained. The added meaning is real but far from compensating for a 0% coverage schema.

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

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

States a specific verb ('Retime') and resource ('character keys') with the scope quantified (2-8 keys) and the transaction semantics called out. It distinguishes itself from plain keyframe tools like set_keyframe by restricting to synchronized/exclusive IK character tracks, though it never names a sibling directly.

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

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

Usage is implied through constraints ('only exclusive IK character tracks', '2-8 complete synchronized character keys'), which tells the agent when the tool is valid and when it will not apply. However, no alternative tool is named for non-synchronized or non-IK cases, and there is no explicit when-to-prefer-this 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?

The description adds substantive behavior beyond the annotations: hard capacity limits (32 per host session, 16 for native history), volatility ('invalid after restart'), and scope ('Saves ONE pose, all Point controls and read-only joint verification; no vendor assets'). With destructiveHint=true already declared, the description usefully characterizes what is stored and how long it survives, though it never explains why the operation is flagged destructive.

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 front-loads the primary memory-snapshot behavior, and each sentence carries information. But it crams three distinct modes into four sentences of jargon ('topology/key guards,' 'bounded native history'), which slows identification of which parameters to use in which case.

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

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

For a 6-param, zero-coverage, no-output-schema tool, the description covers limits, lifetime, and scope reasonably well. It is still missing which parameters are mutually exclusive (scene vs scene_id) and what the snapshot captures for later restore, which the paired restore_pose_snapshot sibling implies but this definition never states.

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% across 6 parameters, so the description must carry the load, and it does partly: it ties scene_id and character_id to the real-character mode, path to the durable .json variant, and frame as optional. It leaves 'scene' (distinct from 'scene_id'), 'root', and the mutual exclusivity of the modes unexplained, so the compensation is incomplete.

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

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

The description names a concrete action and resource: 'Capture all local/global clip transforms and topology/key guards for a Joint subtree in host memory,' and it explicitly distinguishes three storage variants (host memory, native character history, durable .json file). It is specific enough to separate this from generic pose setters, though the three-mode framing makes the core purpose harder to extract at a glance than it should be.

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

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

It gives conditional guidance ('Alternatively supply scene_id and character_id...,' 'Durable variant: scene_id, character_id, absolute new .json path'), which implies when each mode applies. However, it never references the obvious sibling restore_pose_snapshot, nor does it state when to prefer this over save_scene_copy, leaving the agent to infer the round-trip pairing.

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 readOnlyHint=false, and the description goes beyond them by clarifying that existing files are never overwritten (mutation is to a new path), that the call returns a SHA256 of the written file, and, critically, that the native scene identity can change so the caller must rediscover it — a side effect no annotation encodes.

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

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

Three compact clauses, front-loaded with the core action, then the non-overwrite guarantee, then the return value and the identity-change warning. No filler.

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

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

With no output schema, the description still names the return value (SHA256) and warns about the post-call state change, which is exactly what an agent needs before invoking a scene-mutating tool. 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: it clarifies that 'destination' is an absolute .casc path and that a new file is created rather than reused. It adds nothing about 'scene_id', whose 32-hex format is only conveyed by the schema pattern, leaving the compensation partial.

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

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

States a precise verb ('Save') and resource ('the active native scene') plus the exact output artifact ('a NEW absolute .casc file'), and no sibling tool does anything comparable, so it is trivially distinguishable from the transform/pose/export siblings.

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

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

The description implies usage ('Save the active native scene') and gives an important constraint (never overwrite, new file only), but never states when to reach for this tool versus, say, export_fbx or get_scene_info, nor any prerequisite for producing a valid scene_id.

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 destructiveHint/readOnlyHint annotations: discloses transaction atomicity ('ONE native transaction'), automatic full-scene snapshot and rollback verification on failure, retained constraints/IK mode, and the correct behavior after a timeout ('unknown outcome, read back before retry'). This is exactly the operational context a mutation tool needs.

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 transaction semantics, then constraints, then failure handling. Dense but each clause carries signal; slightly run-on phrasing costs a point.

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, no-output-schema, nested-object mutation tool, the description covers atomicity, rollback, prerequisites, and timeout recovery. The remaining gap is identifier semantics (scene_id/character_id) and the shape of the pose payload, which the schema only partially constrains.

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

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

Schema description coverage is 0%, so the description must carry the burden. It clarifies frame bounds (0-120) and that 'pose' is the complete native Point target set, but scene_id and character_id are never explained, and the joint-UUID-to-position mapping in the nested schema is left implicit.

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 ('Write the complete native Point target set'), scopes it to a single native transaction at an existing frame, and distinguishes the native Point workflow from the semantic/transform siblings by naming the exact target type.

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

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

Gives concrete preconditions — 'at an EXISTING frame (0-120)' and 'Exclusive C01 pose editing required' — plus failure-handling advice. It does not, however, explicitly route the agent between this and siblings like set_pose or set_semantic_pose, so no 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 declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds useful context beyond that: it returns the actual frame, and it requires the expected scene name as a validation guard against acting on the wrong scene. It still doesn't explain what state is altered by 'switching' or failure behavior, so it adds value but not rich 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?

A single front-loaded sentence with no wasted words; the mutation verb and the two key constraints (scene validity, frame existence) all appear up front. It is efficient, if terse.

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

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

With no output schema the description appropriately mentions the return ('actual frame'), and annotations cover the destructive/read-only profile. However, for a mutating frame-switch tool it omits what changes to the current frame state, error conditions, and any auth/context requirements, leaving gaps.

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

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

Schema description coverage is 0%, so the description must compensate, and it does partially: 'expected scene name' clarifies that scene is validated against the active scene, and 'existing frame' implies frame must reference a valid existing frame. It doesn't cover the 0–10000 range or format details from the schema, so it is helpful but incomplete.

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 ('Switch to') and resource ('existing frame'), which distinguishes it from the read-only sibling get_current_frame. It doesn't explicitly name alternatives, but the mutation verb and frame target are unambiguous.

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

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

The description implies the operation targets an already-existing frame but offers no when-to-use context, no prerequisites (beyond scene name), and no guidance versus siblings like set_keyframe or get_current_frame. The only hint is the scene-name requirement, which is more parameter semantics than usage routing.

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

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

Annotations already declare destructiveHint=true, but the description adds genuinely valuable behavior: descendants are updated via the host, and a recovery snapshot is captured before mutation. That tempers the destructive flag and tells the agent about propagation and undo safety, which annotations cannot express.

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

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

A single dense sentence with no filler; the side-effect and snapshot facts are informative. Slightly over-packed with three concepts in one clause, but front-loaded and waste-free.

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 6-param mutation with no output schema, the description covers side effects and snapshot recovery but leaves all parameter semantics undocumented. It is usable but leaves real gaps an agent would need to resolve from the schema alone.

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

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

Schema description coverage is 0% across 6 parameters and the description never names or explains any of them (scene, root, object, frame, position, rotation_wxyz). 'One joint in world space' only loosely hints at object/position semantics, leaving the required frame/root/scene params completely 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 (set) and resource (a joint transform in world space), and the phrase 'in world space' implicitly distinguishes it from the local-space sibling set_local_transform. It does not explicitly name or contrast any sibling, so it falls short of a 5.

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

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

'Set one joint in world space' implies the scope (single joint, world-space semantics) versus a batch or local variant, but there is no explicit when-to-use, when-not-to-use, or named alternative guidance despite several closely related sibling tools (set_transform, set_local_transform, set_pose).

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 write/destructive profile (readOnlyHint=false, destructiveHint=true), so the description is not obligated to restate that. It adds genuinely useful context beyond the annotations: atomicity ('one checked native transaction'), non-destructive scope ('preserves existing body keys and interpolation'), and the async read-back pattern ('read back after timeout'). It could say more about failure behavior, but the added behavioral detail is real.

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

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

Three dense sentences that front-load the verb and scope, then the constraints, then the read-back note. Little wasted text, though the jargon ('Cascy finger chains', 'checked native transaction') trades clarity for brevity.

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

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

For a destructive, deeply nested, no-output-schema tool this covers the essentials: what is written, atomicity, what is preserved, and how to confirm via read-back. Missing are failure/rollback semantics and why the read-back is time-delayed, but overall it is complete enough to invoke 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 carry the load. It does clarify the semantic meaning of the poses payload (finger local unit quaternions, 1-8 frames, left/right, validated finger chains) that the bare number-array schema cannot convey. But scene_id and character_id are never explained, so compensation is only partial.

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

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

States a specific verb (Write) and resource (1-8 frames of semantic left/right finger local unit quaternions) in one sentence, and the clause 'not body joints' begins to differentiate it from the body-pose siblings like set_pose_sequence/set_semantic_pose. It never names a sibling explicitly, so differentiation is implied rather than stated.

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?

'Only validated Cascy finger chains, not body joints' gives an implicit when-not condition, steering the agent away from body-joint use. However, no alternative tool is named and there is no explicit guidance on when to prefer this over set_pose_sequence, set_semantic_pose, or set_pose_snapshot.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so safety profile is partly covered. The description adds meaningful behavioral context beyond that: the timeout-is-ambiguous failure mode and the read-back-before-retry guidance, plus the scope constraint that the object must be isolated and unlocked. It does not explain what the destructive annotation actually destroys or the effect on existing keys, so it falls short of 5.

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

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

Three short, front-loaded sentences with zero filler: the operation first, the keying-mode caveat second, the failure/retry rule last. Every sentence carries information an agent needs.

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

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

For a 3-param mutation tool with annotations and no output schema, the description covers scope, preconditions, and the critical ambiguous-timeout behavior. It is nearly complete; the main omission is any statement of what the destructive write affects or whether existing keys are overwritten.

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% for all three parameters, so the description must compensate. It adds real meaning for 'frame' (must already exist) and 'object' (must be isolated and unlocked), but says nothing about 'scene' or the accepted range/format, so it only partially fills the 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 and resource: 'Create a key on an isolated unlocked object's track at an existing frame, preserving pose.' This is precise enough for an agent to know it sets a keyframe rather than a transform. It differentiates from per-channel keying ('Not per-channel keying') but does not name any sibling tool (e.g., set_transform) for contrast.

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?

Provides an implicit precondition ('at an existing frame', 'isolated unlocked object') and an error-handling rule ('Timeout means unknown outcome; read back before retrying'), which is genuinely useful. However, it never states when to choose this over sibling mutation tools like set_transform or set_pose, nor any explicit when-not condition beyond the keying-mode note.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is known. The description adds genuinely useful behavior beyond that: it captures a recovery snapshot first (implying recoverability) and interpolates linear FK tracks, which explains side effects an agent could not infer from the schema.

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

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

Two compact sentences with the core action front-loaded and no filler. The second sentence is dense jargon ('bounded batch engine', 'linear FK tracks') but it carries real information.

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

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

For a destructive 6-parameter mutation tool with no output schema and zero schema documentation, the description leaves key gaps: which parameters are mandatory, what 'frame' means, and what the tool returns. It covers behavior reasonably but not the invocation surface.

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% across 6 parameters (scene, root, object, frame, position, rotation_wxyz), and the description supplies no parameter meaning at all — it never explains units, frame semantics, or what position/rotation arrays represent. No compensation for the coverage gap.

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

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

States a specific verb and resource ('Set one joint in local space') and differentiates from global-space siblings like set_global_transform and set_transform. Slightly muddled by the schema's object/position/rotation arrays, which suggest an object transform rather than a single joint, but the local-space scoping is clear.

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

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

No explicit when-to-use or when-not-to-use guidance, and no sibling alternative is named. 'Local space' implicitly distinguishes it from global-space tools, but the agent must infer that this is the variant to pick for local-space edits.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond them: host transaction atomicity, automatic clip snapshot capture, before/after return, and the crucial timeout-is-unknown-outcome/read-back-before-retry rule. This is exactly the extra behavior an agent needs for a destructive write.

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

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

Four tightly packed sentences, front-loaded with the core action and constraint, then prerequisites, side effects, and the retry hazard. No filler.

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

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

For a destructive 5-param nested-object tool with no output schema, the description covers transactional behavior, snapshotting, returns, and failure handling well. Gaps remain around the meaning of scene/root/space and the units expected, which the schema does not document either.

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

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

Schema coverage is 0%, so the description must carry parameter meaning, and it only partially does – it implies the population and range of pose_data and mentions frame-scale constraints, but never explains scene, root, space (the local/global enum), or the unit/space semantics of the position and rotation_wxyz fields.

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 ('Batch-write 1-32 joints') and the mechanism ('one checked host transaction and one MCP call'), which distinguishes it from single-transform siblings like set_transform and from set_character_pose. The scoping (1-32 joints, linear FK subtree) tells an agent exactly what this tool covers.

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 prerequisites: a <=121-frame, unit-scale, isolated-track linear FK Joint subtree, plus retry guidance for timeouts. It lacks an explicit statement of when to prefer a named alternative (e.g. set_transform for single joints), leaving that routing to inference.

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

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

Goes well beyond the annotations (which only say write/destructive/high safety risk) by disclosing transaction semantics: patches merge with pre-transaction state, failure triggers restoration, unverified recovery locks further writes, no timeline extension, and a read-back requirement after timeout. This is unusually rich behavioral context 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?

Dense but front-loaded: the core action leads, followed by transactional guarantees. Sentences are terse and mostly earn their place, though the failure/recovery clause is packed and could be split.

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, 0%-documented three-param tool with no output schema, the transaction/safety story is complete but the parameter and return-value story is not. An agent still lacks guidance on constructing the poses payload.

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 tool has 3 required nested parameters. The description only vaguely maps to 'frames' (the 1-8 / maxItems limit on poses) and 'semantic Point targets'; it says nothing about scene_id or character_id formats nor the head/chest/pelvis pose structure the schema expects, so it fails to compensate for the coverage gap.

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

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

The description states a specific verb and resource: 'Write 1-8 unique existing frames of semantic Point targets.' This distinguishes it from singular siblings like set_semantic_pose and frame-offset siblings like offset_semantic_pose_sequence, though it never names them explicitly.

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

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

It implies batch usage ('1-8 unique existing frames in ONE ... call') and the transactional context, but gives no explicit when-to-use or when-to-prefer-alternatives guidance relative to set_semantic_pose or offset_semantic_pose_sequence.

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 a destructive mutation, but the description adds substantial context beyond them: single-transaction atomicity, retention of omitted slot targets, preservation of rig constraints, and a timeout-means-unknown-outcome caveat. The note that you read a solver-adjusted result signals the applied values may differ from those supplied, which is exactly the kind of non-obvious behavior an agent needs.

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

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

Three terse clauses front-load the action, then layer the transactional, constraint, and timeout caveats. Every clause carries information; density is high but earned with only minor jargon overhead.

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 nested-parameter mutation with no output schema, the description covers the critical unknowns: transaction scope, omit behavior, constraint preservation, and return/timeout semantics ('read solver-adjusted result'). It stops short on identifying the non-pose params, but the behavioral core is well covered.

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% across 4 params, so the description must carry the load. It explains the core model ('role/slot' names, omit semantics, and 'target frame values' relating to frame), but scene_id, character_id, and frame are never characterized, and no example role/slot names are given.

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 (patch) and resource (named role/slot world-position targets) with clear scope: a partial update in one native transaction. It reads as the 'semantic' pose setter, but it never names or distinguishes itself from close siblings like set_pose, set_character_pose, or set_transform, so the agent must infer the boundary.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative. The omit-behavior sentence ('omitted slots retain the target frame values') is behavioral rather than routing, so an agent cannot tell from the description when to pick this over the many other pose-setting siblings.

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

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

Annotations already declare destructive=true and readOnly=false, but the description adds substantial context: the unlocked/isolated track precondition, the before/after return, and the critical failure-mode guidance that a timeout means an unknown outcome requiring a read-back rather than a blind retry.

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

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

Four dense sentences, front-loaded with the core action and constraint, ending with the retry-safety rule. No filler; every clause carries operational 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 mutation with annotations but no output schema, the definition covers preconditions, the return shape ('before/after'), and failure recovery. Nothing essential an agent needs to invoke it safely 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 coverage the description must compensate, and it resolves the highest-risk ambiguity by specifying the quaternion as '[w,x,y,z]' and clarifying position is world-space with both fields optional. It leaves frame/scene/object semantics to their self-evident names, but the order disambiguation is high-value.

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

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

States a specific verb (set), resource (transform: world position and/or quaternion), and the target (an existing keyframe). The 'world' qualifier helps separate it from set_local_transform/set_global_transform siblings, though those are not named explicitly.

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

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

Provides a precondition ('only isolated unlocked object tracks'), which is useful implicit guidance on when the tool applies. However, it never names alternatives like set_keyframe or set_local_transform, nor the condition that should route the agent away from this tool.

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

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

Annotations declare destructiveHint=true and openWorldHint=false, so safety profile is partly covered; the description adds real behavioral context beyond them — idempotency after auto-stop, ownership restriction, and that it returns frame observations plus stop verification. This is meaningful disclosure for a state-mutating 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?

Three short sentences, zero filler, with the ownership constraint front-loaded ahead of the idempotency and limitation caveats.

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

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

No output schema exists, and the description usefully notes what is returned (frame observations, stop verification) plus idempotency and scope limits. The only real gap is the unexplained scene_id parameter.

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 (scene_id) with 0% schema description coverage, and the description says nothing about what scene_id is, its hex-32 format, or which scene's playback is targeted. With low coverage the description should compensate, and it does not.

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 ('Stop playback') and immediately narrows scope to playback 'owned by this bridge', which distinguishes it from siblings like play_animation. It doesn't explicitly name the sibling it complements, so it falls short of a 5.

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

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

Gives clear when-not guidance ('Cannot stop arbitrary external playback') and a precondition/caveat ('Idempotent after automatic end stop'). No explicit routing to a sibling alternative, but the boundary of what it can act on is unambiguous.

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