unreal_asset_details

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

Annotations cover the read-only/destructive profile (readOnlyHint=true, destructiveHint=false), and the description adds meaningful context beyond that: the conditional loading behavior ('Static meshes may load'), the cm units and data categories returned, class-dependent behavior, and the privacy guarantee ('No content is sent to a provider'). This is genuinely valuable behavioral disclosure that the annotations do not provide.

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, no filler. The purpose is front-loaded, followed by behavioral detail, conditional behavior, and a privacy note. Every sentence earns its place and the whole description is compact for the amount of information it conveys.

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 an output schema present, return-value documentation is already handled, and the single parameter's format is described. The description covers purpose, class-dependent behavior, and data-handling guarantees. The only gap is the lack of explicit alternative-tool routing, but for a one-parameter inspect tool with full annotation coverage, nothing essential for correct invocation 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 must carry the semantic weight for the single 'path' parameter — and it does by specifying the expected format: an exact /Game or /Engine object path. This is the core semantic an agent needs and is not present in the schema. It doesn't mention the 512-char cap, but that is a minor constraint relative to the path-format guidance provided.

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 a specific verb-resource pair ('Inspect one exact /Game or /Engine asset object path') and adds the 'one exact' qualifier that separates it from search/list siblings like unreal_assets. It also names the specific output domains (mesh measurements, registry metadata), so an agent can differentiate it from unreal_asset_dependencies and unreal_asset_import_info without opening their schemas.

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 gives useful context — use for a single exact asset path, and outcomes vary by asset class (static meshes get measurements, other classes get registry metadata). However, it never explicitly names alternatives or states when NOT to use this tool versus siblings like unreal_actor_details or unreal_asset_dependencies; the routing is implied rather than stated.

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