create_character_blueprint

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

With no annotations, the description carries the disclosure burden; it does disclose that the call creates a Character Blueprint with specific default components and optionally adds a camera/spring arm. It does not state side effects such as asset location, overwrite behavior, or whether compilation/saving is required, which leaves some behavioral uncertainty.

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 organized: purpose, included components, Args block, KB pointer, and example; no filler. The Args block is longer but justified because the schema has no property descriptions.

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

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

Given a moderate parameter count, an available output schema, and no annotations, the description covers the creation scope, all parameters, and a KB reference, and includes a minimal example. It could add asset-location/overwrite context, but the agent has enough to invoke the tool 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 Args block must carry parameter meaning; it does, mapping all six parameters to roles (e.g., 'spring_arm_length: SpringArm target arm length'). It does not specify units or the vector order for camera_location/camera_rotation, relying on the schema defaults to complete that information.

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 opens with 'Create a Character Blueprint with optional camera setup' – a specific verb and resource – and enumerates the included components (CapsuleComponent, CharacterMovement, SkeletalMesh), which separates it from generic create_blueprint. It does not explicitly name sibling tools like create_fps_character or create_character_animation_setup, so differentiation is implicit rather than 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?

The first sentence implies the intended use: when a user needs a Character Blueprint with movement and an optional camera. There is no explicit when-not-to-use, prerequisite, or alternative routing among the many sibling blueprint/character tools, so the guidance is only implied.

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