get_blueprint_class_defaults

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

With no annotations, the description carries the full burden. It describes the tool as a read operation (get) that reads the CDO and returns properties. However, it does not explicitly state that it is non-destructive or any potential side effects. The behavior is adequately described but not fully transparent.

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 concise and well-structured: a one-sentence main purpose, a comparison sentence, then a bullet list for parameters. Every sentence adds value without redundancy. It is front-loaded with the core action.

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 that an output schema exists, the description does not need to detail return format. It explains the tool's scope (all editable properties including inherited), the key differentiator from a sibling, and parameter usage. This is sufficient for an agent to correctly select and use the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It provides clear explanations for two of three parameters: 'filter' and 'include_inherited'. The required 'blueprint_path' is not explicitly described but is self-explanatory from context. The descriptions add meaning beyond the schema, especially the case-insensitive note for filter.

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 clearly states its purpose: 'Get all default property values from a Blueprint's generated class CDO.' It uses a specific verb and resource, and distinguishes itself from the sibling tool 'get_blueprint_variable_details' by explaining that this tool includes C++ parent properties.

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 explicitly compares with 'get_blueprint_variable_details' to guide when to use this tool over that one. It does not provide when-not-to-use scenarios, but the alternative is clearly named and contrasted.

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