Skip to main content
Glama

propose_takeoff

Open a named proposal to group pending shapes into one batch, so estimators accept the whole takeoff with a single decision instead of shape by shape.

Instructions

Open a PROPOSAL — a named batch of the shapes you are about to commit, with one identity (#365). Every shape you commit from here on (measure_polygon, measure_line, measure_surface, place_count, the sweeps, the derives, cut_out) attaches to it until you open another proposal or withdraw this one; the estimator then sees ONE Accept pill for the whole batch instead of one per shape — a forty-room pass becomes one decision, not forty. Use it BEFORE the work, the way an estimator titles a takeoff before tracing: "Level 2 rooms per finish schedule A-601", "Base derived from CPT-1 rooms". label is what the estimator reads on the pill; rationale is what decided the batch (the schedule row, the sheet, the rule) — both required, neither is a comment. Nothing here commits geometry or changes a total: an empty proposal is just a heading. The batch is what revise_proposal replaces and withdraw_proposal removes; shapes the estimator has already accepted leave the batch and no agent verb reaches them. takeoff_summary carries the ledger (pending / accepted / withdrawn per batch).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelYesThe batch's title, as the estimator will read it on the Accept pill
rationaleYesWhat decided the batch — cite the schedule row, sheet, or rule

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteYes
labelYes
rationaleYes
proposal_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.21

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it states nothing commits geometry or changes a total, an empty proposal is just a heading, attached verbs (measure_polygon, measure_line, etc.) bind to it until superseded, and accepted shapes leave the batch. It also points to takeoff_summary for ledger state — rich behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose and the key constraint ('nothing here commits geometry'), and every clause is informative. It is on the long side and the label/rationale explanation partly repeats the schema descriptions, costing it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, yet the description still usefully points to takeoff_summary for the pending/accepted/withdrawn ledger. For a two-required-param creation tool with no annotations, the coverage of intent, timing, and side effects is complete.

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

Parameters3/5

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

Schema description coverage is 100%, and the parameter descriptions in the schema are nearly verbatim what the description says (label = what the estimator reads on the pill; rationale = what decided the batch). The description adds framing (neither is a comment) but little syntactic or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Open a PROPOSAL — a named batch of the shapes you are about to commit') and gives it a concrete identity concept (#365). It explicitly distinguishes itself from revise_proposal (replaces) and withdraw_proposal (removes), so an agent can route correctly without opening other schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit timing ('Use it BEFORE the work') and a vivid workflow analogy for the estimator. It names the alternatives by function — revise_proposal replaces the batch, withdraw_proposal removes it — and notes that already-accepted shapes are out of scope, covering when-not as well as when.

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