Skip to main content
Glama
full-aigc-plugins

partme_blender

by full-aigc-plugins
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

validation.prop_handoff

blender_validation_prop_handoff
Read-onlyIdempotent

Verify a Blender constraint handoff over a frame range, checking that the prop transfer completes at the specified catch frame and flags mismatches.

Instructions

PartMe Blender Harness command validation.prop_handoff. Risk: read; maturity: L3. Requirements: Per-request argument checks and session policy still apply

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
boneYes
objectYesStable Blender object locator by name, objectId, or both
armatureYes
frameEndYes
_requestIdNoStable request id for replay safety
catchFrameYes
frameStartYes
_authorizationNoAction-bound Harness authorization claim
_transactionIdNoHarness milestone transaction id
constraintNameYes
_expectedSceneRevisionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.5.3
    • addedInput schema / properties / object / additionalProperties
      Added value: +false
    • addedInput schema / properties / object / anyOf
      Added value: +[
+  {
+    "required": [
+      "name"
+    ]
+  },
+  {
+    "required": [
+      "objectId"
+    ]
+  }
+]
    • addedInput schema / properties / object / description
      Added value: +"Stable Blender object locator by name, objectId, or both"
    • addedInput schema / properties / object / properties
      Added value: +{
+  "name": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "objectId": {
+    "pattern": "^obj_[0-9a-f]{32}$",
+    "type": "string"
+  }
+}
    • changedInput schema / properties / object / type
      Previous value: -"string"New value: +"object"
  2. First observedv0.1.0

TDQS

C2.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'Risk: read; maturity: L3', which reinforces the read-only nature and provides a maturity level, but it does not explain what the command does, what it validates, or what side effects (if any) occur. No contradiction with annotations exists.

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

Conciseness3/5

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

The description is very short, which is concise, but it front-loads only the command name and risk level. The sentence 'PartMe Blender Harness command `validation.prop_handoff`' is largely tautological, and the remaining sentence about argument checks and session policy is generic boilerplate. It is not structured to convey the tool's purpose or usage.

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

Completeness2/5

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

Given 11 parameters, 7 required, nested objects, and an output schema, the description is severely incomplete. It does not explain the command's function, the meaning of key parameters, the expected output, or how it fits into the validation workflow. The output schema exists but the description still needs to provide context for when and why to invoke this tool, which it fails to do.

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

Parameters2/5

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

Schema description coverage is only 36%, and the description provides no parameter explanations. The schema itself documents only `object`, `_requestId`, `_authorization`, `_transactionId`, and `_expectedSceneRevision`; the remaining required parameters (`armature`, `bone`, `catchFrame`, `constraintName`, `frameEnd`, `frameStart`) are bare names with no descriptions. The description does nothing to compensate for this gap, leaving the agent to guess the meaning of core parameters like `catchFrame` and `constraintName`.

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

Purpose2/5

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

The description identifies the tool as a PartMe Blender Harness command named `validation.prop_handoff`, but it never states what the command actually does. The name suggests a validation-related property handoff, yet there is no verb or resource explaining the operation. It does not distinguish itself from sibling validation tools like blender_validation_floor_penetration or blender_validation_foot_drift.

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

Usage Guidelines2/5

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

The description mentions 'Per-request argument checks and session policy still apply', which hints at operational constraints but provides no guidance on when to use this tool versus alternatives. There is no context about the validation scenario, prerequisites, or relationship to other validation commands. An agent cannot determine when this tool is appropriate.

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

Deploy Server

Other Tools