list_constraints

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

The readOnlyHint annotation already establishes that this is a read-only operation, and the word 'List' agrees with that. The description adds the scoping detail that the target can be an object or a pose bone, but does not disclose any further behavioral traits such as whether empty results are returned as an empty list or how errors are surfaced.

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 one short sentence with no filler or repetition. 'List constraints on an object or pose bone' front-loads the action and target efficiently.

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 list tool with only two parameters and an output schema present, the description is roughly sufficient. The main gap is the unresolved relationship with list_bone_constraints and the ambiguity of when to specify bone, which prevents the description from being fully complete on its own.

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

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

Schema description coverage is 0%, so the description must compensate. It maps loosely to the two parameters by mentioning 'object' and 'pose bone', but it does not explain that bone is optional/defaults to null, what format bone values take, or that listing object constraints likely requires bone to be omitted.

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 clear action ('List') and target ('constraints on an object or pose bone'), which distinguishes it from constraint-mutation tools like add_constraint or remove_constraint. However, it does not distinguish itself from the sibling list_bone_constraints, and its mention of 'pose bone' creates possible overlap with that tool.

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

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

The description implies use when constraints need to be enumerated, but gives no explicit guidance about when to choose this tool over list_bone_constraints or other constraint tools. With a close sibling named list_bone_constraints, the absence of 'use X instead' or exclusions leaves the agent guessing.

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