inspect_performance

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

With no annotations, the description carries the full burden and does well: it discloses async queued-then-retry behavior, warns that texture bytes are an RGBA8+mip estimate rather than measured VRAM, notes shared meshes are identified, and explicitly states FPS/draw calls are never inferred. This is a genuinely useful limitation set; only the read-only nature is left implicit.

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?

Front-loaded with the read scope, then compact caveat sentences. Every line earns its place (retry hint, preset budgets, texture-byte caveat, shared-mesh note, FPS/draw-call exclusion). Slightly dense but not padded.

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 4-param tool with no annotations and no output schema, it covers behavior and caveats well, but leaves asset_id unaddressed and wait_seconds (an async timing control) unexplained. Adequate but with a clear remaining gap around parameter-driven latency behavior.

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 coverage is 0%, so the description must compensate, and it explains two of four params: request_id (used to retry a queued request) and preset (mobile_prop/scene_prop/hero_prop, with budgets). asset_id and especially wait_seconds are left undocumented in both schema and description.

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?

States a specific verb (Read) and resource set (native triangles, vertices, material slots, textures, LOD counts), so the agent knows this is an asset performance inspection tool. It is distinguishable from generic inspect_asset/inspect_scene by the performance-metric focus, though it never names a sibling explicitly.

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?

Gives an operational rule (retry with request_id if queued) and names the presets that expose budgets, which implies when to use it. However, it never says when to prefer this over inspect_asset or inspect_library, nor any preconditions or exclusions. Usage 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.