takeoff_summary

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

With no annotations provided, the description carries the full transparency burden and delivers meaningful behavioral context: numbers-only output, coordinate space in image px at render scale 2.0 (PDF pt × 2, origin top-left, y down), and sheet payloads carrying dims in both px and pt. It lacks only an explicit statement about side effects or read-only behavior, but for a zero-parameter summary compute this is reasonably covered.

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 front-loaded with the core computation and unit types, followed by the key sibling differentiator, then the coordinate-system context. Each sentence contributes distinct information — purpose, numbers-only boundary with alternative, coordinate convention, and payload dims — with zero filler or repetition.

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 zero-parameter tool with an output schema present, this description is complete: it covers what is computed, the units and waste variants, the numbers-only deliverable boundary, the coordinate system (px, scale 2.0, origin top-left), and the px/pt relationship in sheet payloads. An agent has everything needed to select and 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?

The input schema has zero parameters, so the description can't add parameter-level meaning; per the rubric, 0 params gets a baseline of 4. The description adds useful return-value context (px/pt dimensions, scale, origin) instead, which is outside the empty schema's scope.

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 identifies the tool's output: per-condition totals (floor/wall/border SF, LF, EA, SY, with/without waste) plus grand totals, tied to 'the Report's numbers.' It explicitly differentiates from the sibling export_marked_pdf by declaring 'Numbers only,' but it doesn't distinguish from other numeric siblings like export_report or export_takeoff, and the verb 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 description gives an explicit when-not-to-use signal: 'Numbers only' and 'the deliverable that SHOWS the work on the drawings is export_marked_pdf,' directing agents to the visual alternative. However, it doesn't address other relevant siblings (export_report, export_takeoff, sweep_schedule_row), so usage guidance is partial rather than comprehensive.

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