Fire compute aset

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral context beyond them: what is returned (ASET per point, governing criterion, a lower bound when nothing is exceeded, which quantities are missing), the source fallback logic, and the remediation path. It stops short of stating return units or the cost/method of the slice read.

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 core computation and defaults, then return semantics, then the missing-data remediation. It is dense with nested parentheticals, but each clause carries distinct information (defaults, point derivation, rule IDs) rather than restating the name.

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 complex, nested-object tool with no output schema, the description covers defaults, return content, fallback behavior, and a remediation loop, and points to bulc rule IDs. It would be fully complete with the ASET time unit and explicit sibling contrast, but nothing essential to a correct call 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?

With 50% schema coverage, the description compensates substantially: it defines the points default (every user exit) and the floorZ/story meaning, restates the criteria defaults and samplingHeight, and explains the source auto-preference (slices, then Plot3D). This adds meaning beyond the schema's enum and field descriptions, though fdsPath defaulting is left to the schema.

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 (compute) and resource (ASET at breathing height) with the governing physics (floor + samplingHeight, slices vs Plot3D, criteria set). It is clearly distinguishable from siblings like fire_results_summary and fire_timeseries, which summarize or export results rather than derive an egress-time metric.

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 explicit conditional routing: if required quantities are missing, add output_add_tenability_slices and re-run, and it names the default point source (user exits, OPEN vents, door items, Door_/Window_ holes). It does not, however, contrast itself against fire_timeseries or fire_results_summary, so the when-to-use-this-vs-that is only partially covered.

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