Server Quality Checklist

Tool Scores

• delete_shapeB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. It does not disclose destructive nature beyond 'Remove', nor does it mention reversibility, permissions, or error behavior. The unrelated coordinate information does not contribute to behavioral transparency.

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

  Conciseness2/5

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

  The first sentence is concise and effective, but the second sentence about coordinates is unrelated to the tool's parameters and adds noise, violating the 'every sentence earns its place' principle.

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

  Completeness2/5

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

  Despite having an output schema, the description doesn't explain operation outcomes, idempotency, or side effects. The tool is simple but the description is incomplete and includes irrelevant coordinate context that distracts from core functionality.

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

  Parameters4/5

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

  The description adds meaning to shape_id by specifying it is the id returned at commit time, which is not in the schema. However, the coordinate sentence is irrelevant and could confuse parameter expectations.

  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?

  Description clearly states the verb 'Remove', the resource 'committed shape', and the identifier 'id returned when it was committed'. It distinguishes from siblings like edit_shape by focusing on deletion of committed shapes.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives. The description provides no context about when deletion is appropriate, prerequisites, or exclusions relative to sibling tools like cut_out or edit_shape.

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

• export_takeoffA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and discloses important behaviors: coordinate system (scale 2.0, origin top-left, y down), inline return vs disk write, and overwrite semantics (requires overwrite flag for non-OpenTakeoff files). It does not explicitly state that the takeoff data itself is unmodified, but export implies read-only.

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

  Conciseness5/5

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

  The description is a single, dense sentence packed with essential information. It is front-loaded with the core purpose and every clause contributes meaning, with no fluff or repetition.

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

  Completeness4/5

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

  The description adequately covers the payload format, coordinate system, optional disk write, and overwrite behavior. Since an output schema exists, return values are documented separately. Minor gap: no reference to sibling tools for comparison, but overall it is complete for a technical export tool.

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

  Parameters4/5

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

  The schema already provides high coverage (100%) for both parameters. The description adds value by clarifying that the payload is returned inline by default and that passing 'path' writes to disk, which explains the relationship between parameters and output beyond the schema's individual descriptions.

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

  Purpose4/5

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

  The description clearly indicates the tool returns the full 'opentakeoff.takeoff_canvas.v1' annotations payload, which is the app's autosaved format. It distinguishes from siblings like export_report and import_takeoff by focusing on the raw canvas payload, but uses technical jargon that may obscure the simple 'export' action.

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

  Usage Guidelines3/5

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

  The description implies usage for exporting/backing up the annotations payload and optionally writing to disk. It does not explicitly compare with alternatives like export_report or mention when not to use this tool, so guidance is present but not fully explicit.

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

• measure_lineA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses coordinate system (image px at render scale 2.0, origin top-left, y-down), scale requirement, and that sheet payloads carry dims in px and pt. It doesn't mention destructiveness or auth, but for a read-like measurement tool, these are less critical.

  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?

  The description is well-structured, starting with verb and purpose, then key constraints. Every sentence adds value (coordinate details, scale requirement, condition usage). It could be slightly tightened (e.g., merging coordinate and sheet payload sentences) but is efficient overall.

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

  Completeness4/5

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

  For a tool with 3 parameters and an output schema, the description covers purpose, prerequisites, coordinate system, and one param's role. It lacks details on return values (output schema presumably covers that) and error cases. The sheet param missing is a gap, but overall it provides sufficient context for typical use.

  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 coverage is 0%, so description must compensate. It explains 'pts' as polyline points and 'condition' as committing as a linear shape. However, 'sheet' is not described at all (likely an ID or key). This leaves one of three parameters unexplained, which is a gap given zero schema help.

  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?

  The description clearly states the tool measures an open polyline's length in linear feet at the sheet's scale, contrasting with siblings like measure_polygon (likely area). The verb 'Measure' and specific resource 'open polyline' make the action unambiguous.

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

  Usage Guidelines4/5

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

  It specifies a prerequisite ('Requires the scale to be set') and mentions passing a condition to commit as a linear shape. Though it doesn't explicitly list alternatives, the sibling context (e.g., measure_polygon for closed shapes, set_scale for scale) provides implicit guidance. Could be more directive about when not to use.

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

• measure_polygonA
  4.1/5.0
  Behavior4/5

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

  With no annotations available, the description takes on the full burden. It discloses the non-obvious coordinate system (render scale 2.0, top-left origin, y-down), the need for a scale, and the role-based subtraction behavior. The 'commit' phrasing is ambiguous, but overall it provides substantial behavioral context.

  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?

  The description is four sentences and front-loads the core purpose. It packs important details about coordinate systems and prerequisites without excessive verbosity. The phrase 'Pass condition to commit it' is cryptic but does not waste words.

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

  Completeness4/5

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

  Given the output schema covers return values, the description doesn't need to explain them. It covers prerequisites, coordinate system, role behavior, and sheet context, which is strong for a tool with no annotations. It could be clearer on the commit semantics but is overall complete.

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

  Parameters4/5

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

  The schema has 0% description coverage, so the description must compensate. It adds key meaning to 'verts' (image px, closed polygon, min 3 vertices, coordinate space), clarifies 'role' (deduct subtracts), and explains 'condition' (commit). Only 'sheet' remains vague, but it is likely a standard reference.

  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?

  The description clearly states the tool measures a supplied closed polygon (min 3 vertices) and reports area_sf and perimeter_lf at the sheet's scale. This immediately differentiates it from sibling tools like measure_line and measure_surface.

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

  Usage Guidelines3/5

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

  The description provides a prerequisite (scale must be set) and explains conditional behavior (passing a condition commits it, role 'deduct' subtracts). However, it does not explicitly discuss when to use this tool vs. alternatives such as measure_line or measure_surface, so the guidance remains implied.

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

• one_clickA
  4.2/5.0
  Behavior5/5

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

  With no annotations, the description carries full transparency burden and does so extensively. It discloses synthetic boundary from gap sealing (gap_sealed_px), door-swing wedges (door_wedges), the meaning of confidence, automatic raster fallback for scanned sheets, and the exact coordinate system (render scale 2.0, origin top-left, y down). It even warns that '1.0 means every signal ran clean, not that the trace is right'. This is exceptionally rich behavioral disclosure.

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

  Conciseness3/5

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

  The description is front-loaded with the core purpose, but it is very long and includes repeated audit warnings ('put eyes on the flagged edge', 'LOOK at what landed', 'audit it'). While almost every sentence adds technical detail, the redundancy and dense jargon make it less concise than it could be. It earns a mid score for structure over length.

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

  Completeness4/5

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

  For an 8-parameter tool with no annotations, the description covers most critical contextual areas: scale dependency, raster fallback, commit semantics, confidence as a review tool, coordinate system, and post-commit verification. It lacks explicit detail on layers and sensitivity, but those are documented in the input schema. Given the tool's complexity, the description is near-complete, though not perfectly exhaustive.

  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 only 50%, so the description must compensate for x, y, role, and sheet. It does explain x/y as image px click coordinates, role's deduct behavior, and condition as a finish tag. However, it omits the layers override, sensitivity knob, and return_verts flag entirely, leaving those to schema descriptions. It adds meaningful semantics for some parameters but not all.

  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?

  The description leads with a specific verb and resource: 'click inside a room (image px) and the plan's vector linework bounds it — the sealed flood engine'. This clearly distinguishes one_click as an automatic area-tracing tool, unlike sibling tools such as measure_polygon or detect_rooms. It also specifies the commit behavior and role semantics, making the purpose unmistakable.

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

  Usage Guidelines4/5

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

  The description gives concrete usage context: 'With the sheet's scale set, returns area_sf / perimeter_lf', 'Without a scale it returns px-only quantities with a warning and commits nothing', and explicitly says 'role "deduct" makes the committed shape subtract'. It recommends setting scale first and auditing afterward with view_sheet, and mentions using edit_shape for fixes. However, it never explicitly compares against sibling tools like measure_polygon or detect_rooms, so it stops short of full when-to-use versus alternatives guidance.

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

• takeoff_summaryA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• list_shapesA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosing behavior. It states the operation is a 'compact read', implying non-destructive, and clarifies that it only includes 'committed' shapes, not drafts. It also notes that filters narrow results, which informs the caller about side effects. However, it does not explicitly mention authorization needs or potential error conditions beyond the schema's 'condition must exist'.

  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?

  The description is informative and front-loaded with the core purpose. It uses three sentences: the first lists the returned fields and positions the tool, the second explains its use case relative to siblings, and the third clarifies filter semantics. While the first sentence is long, every part adds value, so it earns its place.

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

  Completeness4/5

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

  The output schema exists, so return values are covered. The description explains what fields are included, how filters behave, and when to use it, which is sufficient for a read-only list tool. It could mention potential errors (e.g., invalid condition), but the schema already notes the condition must exist, making this reasonably 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?

  The schema covers both parameters with clear descriptions ('Only shapes on this sheet', 'Only shapes under this finish tag (must exist)'), so the description adds limited new meaning. It reinforces that the two filters can be combined and that they narrow results, but this does not go significantly beyond the schema. Baseline of 3 is appropriate given high schema coverage.

  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?

  The description clearly states the tool lists all committed shapes with specific fields (id, sheet, condition tag, etc.), using the verb 'list' plus the resource 'shapes'. It distinguishes itself from siblings by positioning it as a compact read that provides ids for edit_shape and delete_shape without pulling the full export_takeoff payload.

  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?

  The description explicitly states when to use this tool: to obtain ids that edit_shape and delete_shape assume, while avoiding the heavier export_takeoff. It also clarifies that filters (by sheet, condition) narrow results and that an empty list is a valid result, not an error, which sets user expectations.

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

• sheet_infoA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden, and it does so well by disclosing the coordinate system (image px at render scale 2.0, origin top-left, y down) and that the payload includes both px and pt dimensions. It also transparently notes the raster_traced fallback for scanned sheets, adding behavioral context beyond what a simple 'get info' would imply.

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

  Conciseness5/5

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

  The description is compact and front-loaded with 'Sheet detail:' followed by a dense list of attributes. The two additional sentences on coordinate space and payload dimensions are valuable and non-redundant; every sentence earns its place.

  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?

  Given the tool has a simple single parameter and an output schema (not shown), the description covers the necessary context: what values are returned, what the coordinate system is, and how the vector/raster distinction affects downstream tools. It is complete for an information-retrieval tool.

  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?

  The input schema already documents the single 'sheet' parameter with 100% coverage, giving examples of sheet keys and title-block numbers. The description does not add further meaning about the parameter, so the baseline score of 3 is appropriate; the schema fully handles parameter semantics.

  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?

  The description opens with 'Sheet detail:' and enumerates specific attributes (dims, vector segment count, linework type, scale status, shape count), making the tool's purpose unmistakable. It also references the sibling tool one_click, which distinguishes its role in diagnosing whether a sheet will flood or fall back to raster tracing.

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

  Usage Guidelines4/5

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

  The description explains that sheet_info reports whether vector linework is present, which is directly relevant to whether one_click will flood or use rendered pixels. This provides clear context for when to consult sheet_info before invoking one_click, though it stops short of an explicit 'use this when...' or naming other alternatives.

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

• link_annotationA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description carries burden. Discloses key behavior: detaching via empty string and tag minting on first use. Could mention more side effects, but adequate.

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

  Conciseness5/5

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

  Three sentences, front-loaded with primary function, followed by use cases and a behavioral note. No redundant information.

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

  Completeness4/5

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

  Given tool simplicity and existence of output schema, description covers purpose, usage, and key behavior. Does not address errors or edge cases, but sufficient for typical use.

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

  Parameters4/5

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

  Schema coverage is 100% with clear parameter descriptions. Description adds extra context: 'list_annotations' for IDs and tag minting, enhancing meaning beyond schema.

  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?

  The description states the verb 'attach' or 'detach' and the resource 'annotation' and 'condition', clearly distinguishing from siblings like 'annotate' and 'list_annotations' by referencing them. It explains primary function and use cases.

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

  Usage Guidelines4/5

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

  Provides explicit use cases: tie up unattached notes or move annotations to correct conditions. References sibling 'list_annotations' for context. Does not list when not to use, but guidance is sufficient.

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

• resolve_tagA
  4.4/5.0
  Behavior5/5

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

  With no annotations to fall back on, the description thoroughly discloses behavioral traits: refusal over guessing, 'unresolved' status on ambiguity, handling of reused numbers, building-qualified tags, delta/REV tags and their effect (post-revision answer), and the image coordinate system (px at render scale 2.0, top-left origin, y down). This is far beyond what annotations would provide.

  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?

  The description is a single dense paragraph, but logically ordered: from plan tag to schedule rows to finish codes, then evidence and edge cases. Each sentence adds necessary information. It is long but appropriately packed with essential behavior for a complex tool.

  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?

  Given the tool's complexity (multi-step resolution, continuation sheets, ambiguity handling, building-qualified tags, revision markers, coordinate system), the description covers all crucial context. It explains edge cases, coordinate details, and the link to view_sheet. The existing output schema handles return values, so the description is complete for selection and invocation.

  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?

  The single parameter 'tag' is fully described in the schema (including examples and building-qualified syntax). The description adds little beyond restating the schema's parameter description, though it does reinforce the resolution context. Since schema coverage is 100%, baseline 3 is appropriate.

  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?

  The description clearly identifies the tool's action: resolving a single room tag across the entire set, tracing through schedule rows and finish definitions, and outputting evidence pointers. It distinguishes itself from sibling tools like sweep or find_text by specifying the multi-step resolution chain, making its purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides strong contextual guidance: it explains when to use the tool (to resolve a room tag end-to-end), how to handle multi-building sets, and that view_sheet should be used to inspect evidence. While it doesn't explicitly name alternative tools for non-resolution tasks, it implicitly distinguishes itself by describing a unique workflow, and the mention of view_sheet for evidence checking gives practical usage direction.

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

• set_scaleA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses important behavioral details: coordinates are image px at render scale 2.0 with origin top-left and y-down, and the detected scale is never applied automatically. This goes beyond the schema by explaining the rendering coordinate space. It does not mention side effects like overwriting an existing scale, but the provided context is substantial.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the core action, and every sentence adds distinct value: mode enumeration, automatic-detection caveat, and coordinate system. No redundant or vague phrasing.

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

  Completeness4/5

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

  For a tool with 5 parameters and a nested object, the description covers the essential context: modes, coordinate semantics, and the explicit-call requirement. A return value is not described, but an output schema exists. The description is sufficiently complete for an agent to invoke the tool correctly, though it does not explain how sheet is identified or what happens to prior scale settings.

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

  Parameters4/5

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

  Schema description coverage is 80%, so the baseline is 3. The description adds meaning by explaining the coordinate system for calibrate points, giving an example label format, and clarifying that use_detected adopts the drawn scale note. It also clarifies the 'exactly as listed in the error' for label, which helps with validation. This exceeds baseline.

  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?

  The description opens with a specific verb+resource: 'Set a sheet's scale'. It then enumerates the four mutually exclusive modes (label, upp, calibrate, use_detected), clearly distinguishing this tool from measurement or detection siblings. The added note that the detected scale is never applied automatically further clarifies its unique role.

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

  Usage Guidelines4/5

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

  The description explicitly states 'exactly ONE of' and explains each mode's purpose, giving clear context on when to use which option. It also warns that detected scale is never automatic, so the agent knows to call this tool explicitly to adopt it. However, it does not name alternatives or state when not to use this tool, so it stops short of full exclusionary guidance.

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

• delete_verdictA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It states the operation is a mutation ('Journaled like every mutation'), reveals that it refuses human APPROVED seals, and explains that undo_last can re-seat a lifted mark. This is substantial and goes beyond the basic schema.

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

  Conciseness5/5

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

  The description is three sentences with no filler. It front-loads the action, then packs in the essential details: source of the ID, restriction on human seals, and undo/redo behavior. Every sentence earns its place.

  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?

  For a single-parameter tool with an output schema and no annotations, the description is remarkably complete. It covers purpose, valid ID sources, exclusivity of agent marks, the mutation/journaling behavior, and reversibility via undo_last. Nothing critical is missing for correct invocation.

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

  Parameters4/5

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

  The schema already fully documents verdict_id with the same source reference, but the description adds important semantic context by clarifying that only agent marks are valid and that human APPROVED seals are refused. This helps the agent understand which IDs are acceptable.

  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?

  The description uses a specific verb and resource: 'Lift an agent verdict mark by id', and immediately tells the reader where to find valid IDs ('mark_verdict's reply, or list_annotations verdicts[]'). This clearly distinguishes it from sibling tools like delete_shape or mark_verdict.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: only agent verdict marks can be lifted, while the estimator's APPROVED seal is refused. It also mentions the undo_last journaling behavior, giving the reader practical when-to-use and what-to-expect guidance, though it does not explicitly name alternative tools for comparison.

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

• export_reportA
  4.5/5.0
  Behavior4/5

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

  No annotations exist, so the description carries full burden. It discloses that the call returns an inline JSON and optionally writes to disk via path ('Returned inline; pass path to also write it to disk as JSON'). It clarifies the schema compatibility and that it is computed. However, it does not explicitly state side-effect safety (e.g., no project changes) or any failure conditions, which would push it to 5.

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

  Conciseness5/5

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

  The description is front-loaded with a precise definition, then logically flows through contents, sibling contrast, usage guidance, and output behavior. Each sentence adds new information—no filler or repetition of schema. Despite length, it earns its place.

  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?

  The tool is complex, but the description thoroughly covers contents, use case, alternatives, and complementary tools. It also explains the 'half deliverable' pairing rationale. With an output schema present, the detailed return-value enumeration still adds value by explaining what the report computes and why it matters.

  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 coverage is 100% with each parameter ('path', 'overwrite', 'project_name') already documented. The description only indirectly references path ('pass path to also write it to disk') and does not add new meaning beyond the schema. Baseline 3 is appropriate.

  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?

  The description opens with 'The computed Report document — "opentakeoff.report.v1"' immediately identifying the tool as producing a specific, computed report. It enumerates detailed contents (per-condition quantities with waste/multiplier, BUY LIST, roll-ups, per-sheet subtotals, scale provenance, annotations) and explicitly contrasts with export_takeoff and takeoff_summary, making it unmistakable from siblings.

  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?

  Explicit guidance is given: 'when the numbers are leaving for pricing, consume this.' It also says 'A report alone is HALF the deliverable: pair it with export_marked_pdf' and contrasts with raw payload export_takeoff and compact takeoff_summary. This clearly states when to use, when not to, and recommends a complementary sibling.

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

• split_conditionA
  4.5/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 excellently. It discloses key behavioral consequences: following rows freeze, edits stop propagating, finish tag is kept, grouping remains, and the operation is reversible with undo_last. It also explains the non-erroring split:false case, which is valuable safety information.

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

  Conciseness5/5

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

  The description is compact yet information-dense, using four sentences to cover purpose, effects, usage guidance, edge-case behavior, and reversibility. Every sentence earns its place with no filler or repetition of schema details.

  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?

  For a single-parameter tool with an output schema, the description provides comprehensive context: what happens to the data, when to invoke it, what happens in a specific edge case, and how to undo it. The existence of an output schema means return-value details are not required in the description.

  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?

  The schema already provides 100% coverage for the single 'condition' parameter with a clear description and example. The tool description reinforces the concept by repeatedly referencing 'finish tag' and 'twin', adding some semantic context, but does not significantly exceed what the schema documents.

  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?

  The description clearly states the specific action ('Cut a twin loose from its family') and the resource (a condition/twin), while detailing the effect: inheritance ends, materials freeze. It distinguishes itself from sibling tools like duplicate_condition by explaining that this tool severs inheritance rather than duplicating.

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

  Usage Guidelines4/5

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

  It provides explicit use case: 'Use when two variants have diverged far enough that following one another is wrong.' It also describes behavior for an edge case (already-owned condition returns split:false) and reversibility, but does not explicitly mention when not to use it or name alternative tools.

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

• apply_rulesA
  4.6/5.0
  Behavior5/5

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

  No annotations exist, so the description carries full burden. It discloses key behavioral traits: deterministic (not a re-prompt), uses the same rules.ts engine as Preview, commits as a single batch reversible by undo_last, marked reviewed:false, includes per-rule disclosure in the reply, and is idempotent. It also notes refusal when no rules are imported and skipped_sheets for uncalibrated/raster sheets.

  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?

  The description is long but every sentence contributes essential behavioral context for a tool with no annotations and nuanced semantics. It is front-loaded with the core purpose then layers details about evaluation, commit, idempotency, import gate, and skipped sheets, making it dense but not wasteful.

  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?

  The description fully covers the tool's behavior for its single-parameter interface: it explains the default scope, output behavior (per-rule disclosure serving as preview), error conditions (refuses without imports), and edge cases (skipped sheets). An output schema exists, and the description complements it by describing the meaning of skipped_sheets and the preview nature of the reply.

  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 tool has only one optional 'sheet' parameter. The description restates the schema ('Pass sheet to scan one sheet; omit it to scan every sheet holding the rules' rooms') without adding new meaning, so it stays at the baseline for high schema coverage.

  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?

  The description clearly states the tool re-runs correction rules, identifying them as deterministic predicates ('enclosed linework islands under a size cap') and ties them to the canvas's Apply action. It distinguishes from siblings by noting rules arrive only via import_takeoff and that undo_last can reverse the batch.

  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?

  Explicit when-to-use guidance is provided: re-running after new rooms commit is the intended workflow, and it is safe due to idempotency. The description also contrasts with alternatives: rules only via import_takeoff, preview via view_sheet, and undo via undo_last.

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

• export_marked_pdfA
  4.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 behavioral burden. It discloses that the tool writes a PDF to disk, states the default path, notes the machine-traced warning page, clarifies it needs no native canvas, and confirms it is built from the same module as the app button. These are meaningful behavioral details 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?

  The description is front-loaded with the core purpose and fairly dense, but it is longer than necessary. Several phrases could be tightened (e.g., 'The MARKED-UP PLANSET — the deliverable of every takeoff' and later 'A construction takeoff is no good without markup'). Still, most sentences earn their place, covering content, workflow, caveats, and edge cases.

  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?

  Given the tool's complexity and the presence of an output schema, the description is remarkably complete. It explains what the PDF contains, when to use it, how it relates to other workflows, the machine-traced caveat, the default path, and the no-canvas requirement. There are no obvious gaps for an agent to invoke it correctly.

  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%, so the baseline is 3. The description only reiterates the default path for the 'path' parameter and does not add deeper meaning for 'overwrite' or 'project_name.' It adds no practical usage nuances beyond what the schema already states.

  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?

  The description clearly states a specific deliverable: 'Writes a distribution-ready PDF to disk' and enumerates its contents (legend cover, vector-copied sheets, quantity chips, annotation clouds). It explicitly differentiates from siblings: 'export_report carries the numbers for pricing; this carries the evidence,' and notes it is the same module as the canvas's MARKED SET button.

  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?

  Provides explicit when-to-use guidance: 'finish EVERY takeoff by writing this file and giving the user its path.' It contrasts with exports ('export_report carries the numbers... this carries the evidence') and notes a conditional usage context ('When the shapes were machine-traced and unreviewed... the review path is importing the export_takeoff payload'). Also mentions it works even where view_sheet cannot render, implying a fallback use case.

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

• find_textA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the behavioral disclosure burden. It details case-insensitive substring matching, pdf.js text run splitting, coordinate system (image px at render scale 2.0, origin top-left, y down), result capping, and count/truncated fields. This is comprehensive.

  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?

  The description is a single, information-dense paragraph. It front-loads the purpose and workflow, but could be more structured with bullet points or sections. However, every sentence adds value, and there is no redundancy.

  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?

  Given the existence of an output schema (not shown), the description does not need to detail return values. It covers coordinate system, region restriction, limit behavior, and workflow integration. For a find_text tool, this is complete and actionable.

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

  Parameters4/5

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

  Schema coverage is 75% (3 of 4 parameters described). The description adds value beyond the schema by explaining coordinate semantics for the region parameter, case-insensitive behavior for q, and default/max behavior for limit. The undocumented sheet parameter is minor.

  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?

  The description clearly states the tool's function: 'LOCATE a known string on a sheet' and explicitly distinguishes it from the sibling tool read_sheet_text, which returns what a region says. The verb 'locate' and resource 'string on a sheet' are specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear usage context, including the locate-then-trace workflow with one_click, and explains the behavior for fragmented text runs. It does not explicitly state when not to use it, but the guidance is strong and the scenario is concrete.

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

• import_takeoffA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does so richly: it discloses merge rules (finish-tag identity, duplicate skip, idempotency), calibration precedence, reviewed-shape protection, unknown_files behavior, approval-mark transport, and undo semantics. No annotation contradiction exists.

  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?

  The description is long but appropriately dense, with each sentence carrying meaningful behavioral or usage information. The opening 'The way BACK IN (#151)' is slightly cryptic but not harmful; overall it is well-structured and front-loaded.

  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?

  Covers all necessary context: preconditions, merge behavior, return field (unknown_files), limitations with other-file shapes, and undo impact. Given the complexity and the existence of an output schema, the description is fully self-sufficient.

  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 coverage is 100% for the single 'path' parameter, and the description does not add significant new parameter-level detail beyond referring to the file type already in the schema. 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?

  The description clearly identifies 'load an opentakeoff.takeoff_canvas.v1 file' into the session, specifying the exact file type and operation. It distinguishes itself from siblings by naming export_takeoff as the counterpart and load_plan as a different resource (plan vs canvas).

  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?

  Explicitly lists use cases: 'Resume yesterday's work, extend a takeoff a human already reviewed... or audit someone else's export with list_shapes/takeoff_summary.' Also states the prerequisite 'Requires a loaded plan' and references the Sheet-menu import as an alternative with the same merge rules.

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

• measure_surfaceA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and handles it exceptionally well. It discloses the refusal behavior when height is not set (mints nothing), the undo-step journaling of height_ft, the coordinate system (image px, render scale 2.0, origin top-left, y down), and that the shape snapshots the height used. This level of detail goes beyond typical descriptions.

  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?

  The description is dense but not bloated; every sentence earns its place. It front-loads the purpose and packs constraints, prerequisites, and coordinate details efficiently. It could be slightly more parseable with clearer separation of topics, but it is far from verbose and maintains a logical flow.

  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?

  Despite the tool's complexity (4 parameters, no annotations, output schema exists), the description covers purpose, usage, prerequisites, failure behavior, and coordinate details. Since an output schema exists, not explaining return values is acceptable. The description also differentiates from siblings, making it fully contextual for an agent to invoke correctly.

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

  Parameters4/5

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

  Schema coverage is 75%, so the baseline is 3. The description adds meaningful context: it clarifies that pts are image px in an open polyline (min 2 points), that height_ft is written to the condition's H knob before being used, and that sheet payloads carry dims in both px and pt. However, the 'sheet' parameter itself is still not explicitly described, which is a minor gap given it's a required string.

  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?

  The description clearly states the tool's function: measuring surface area of walls by tracing an open run in plan view, with the quantity given as LF × height. It explicitly distinguishes itself from siblings by noting that one_click and measure_polygon cannot produce this takeoff, making the purpose and scope unambiguous.

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

  Usage Guidelines4/5

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

  The description provides solid usage context: it is for wall tile, wainscot, and wall systems, and explicitly states that one_click and measure_polygon cannot produce this. It also requires the sheet's scale and height to be set, but doesn't explicitly enumerate when not to use it or mention alternatives like measure_line. Still, the guidance is clear enough for an agent to choose appropriately.

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

• place_countA
  4.6/5.0
  Behavior5/5

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

  Annotations are absent, so the description fully carries the burden and does so thoroughly. It discloses the exact computed shape ({count: 1}), the single-undo-step behavior, coordinate system conventions (image px, render scale 2.0, origin top-left, y down), and how results appear in takeoff_summary and the marked set.

  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?

  The description is dense and every sentence adds unique information, from core purpose to coordinate details. It is front-loaded with the primary function. While somewhat long, the length is justified by the complexity of coordinate systems and undo behavior.

  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?

  With an output schema present, return values need not be described. The description covers operational behavior, coordinate transformations, undo grouping, scale requirement (none), and how the results are reported. For a 3-parameter tool with an array parameter, this is highly complete without obvious gaps.

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

  Parameters4/5

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

  Schema covers 67% of parameters (points and condition have descriptions). The description adds critical meaning for 'points' by specifying the coordinate system (render scale, origin, y-down) and for 'condition' by explaining finish-tag commitment. The 'sheet' parameter lacks schema description but the description mentions dimensional payloads, partially compensating.

  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?

  The description clearly states the tool's function: 'Count markers' with one count shape per point. It distinguishes itself from siblings by identifying the 'scale-free quantity family' and explicitly stating 'NO scale required', contrasting with measure tools like measure_line or measure_surface.

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

  Usage Guidelines4/5

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

  Provides clear context for when to use this tool: counting EA items (thresholds, stair nosings, etc.) that are counted as each, not measured. It explicitly states no scale is required, implying it is for use without scale, but does not name specific alternative tools or explicitly exclude edge cases.

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

• sweep_schedule_rowA
  4.6/5.0
  Behavior5/5

  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 surpasses expectations. It discloses commit semantics ('commits the counted matches as EA markers under the row's own key — one undo step'), refusal conditions, the `scale_assumed` disclosure instead of a confident zero, and coordinate-space details. The section on what counts vs. is excluded vs. withheld is particularly detailed and honest about the system's behavior.

  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?

  At ~400 words, this is a long description, but nearly every sentence earns its place — covering match-counting rules, scale behavior, refusal conditions, and coordinate systems without repetition. The density of unique information justifies the length, though a short example or heading structure could aid scannability.

  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?

  For a tool with this level of algorithmic complexity — fingerprint anchoring, corroboration, scale handling — the description explains return evidence (`tag_at`), edge cases (`text_only`, `scale_assumed`), the fallback path, and even post-commit verification steps. The presence of an output schema offsets the need to document return values in detail, and the description fills in the behavioral gaps thoroughly.

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

  Parameters4/5

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

  Schema coverage is 100% across 5 parameters, satisfying the baseline-3 standard. The description enriches parameter understanding by explaining how `tag` becomes the condition tag, how `commit: true` interacts with match types (excluded/withheld/text_only never commit), and how `mirror`/`rotations`/scale affect matching. The parameter semantics benefit from the description, elevating it above the minimum baseline.

  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?

  The description opens with 'Take off a schedule row's mark from the row itself' and details a specific verb+resource with an exact 3-step process (reads/binds the row, anchors a fingerprint, sweeps all PLAN-role sheets). It explicitly distinguishes itself from the sibling `symbol_sweep` by naming it as the fallback, which differentiates it from a tool in the same domain.

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

  Usage Guidelines4/5

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

  The description provides explicit context for when to use this tool — the estimator's gesture of a transition type living only as a schedule row plus tag markers — and lists concrete refusal/fix scenarios (no such row, ambiguous duplicate keys, no plan sheet, no repeatable linework). It also names the alternative `symbol_sweep` as the fallback path. It could go further in contrasting with additional siblings like `resolve_tag` or `find_schedule`, but the usage context is otherwise strong.

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

• read_sheet_textA
  4.7/5.0
  Behavior5/5

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

  Since no annotations are provided, the description fully carries the transparency burden. It discloses the coordinate system (image px, origin top-left, y down, render scale 2.0), explains the return format, and notes how sheet payloads carry dimensions in both px and pt. No behavioral surprises are left unmentioned.

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

  Conciseness5/5

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

  The description is five sentences long, front-loaded with the core functionality ('The sheet's text with positions'), followed by optional behavior, use cases, coordinate details, and dims note. Every sentence adds value without redundancy or verbosity.

  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?

  Given the tool's moderate complexity (2 params, one nested) and the presence of an output schema (so return values need not be reiterated), the description covers all essential aspects: purpose, parameter formats, coordinate system, and typical use cases. It is sufficiently complete for an agent to invoke correctly.

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

  Parameters4/5

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

  The input schema has 2 parameters (sheet, region) with 0% description coverage, so the description must compensate. It explains the optional region parameter's format and coordinate significance, and it clarifies coordinate space for region values. The 'sheet' parameter is not elaborated, but its purpose is inferable from context. The description adds meaningful value beyond the raw schema.

  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?

  The description clearly states the tool reads sheet text with positions, including the structure '[{str, x, y}]' and joined text. It provides concrete use cases (title blocks, room labels, etc.) and distinguishes itself from sibling tools like 'sheet_info' (metadata) or 'measure_*' (measurements), making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Use it to read title blocks, room labels, finish schedules, and scale notes,' giving clear guidance on when to apply the tool. However, it does not explicitly state when not to use it or contrast with siblings, though the context of siblings (delete, measure, etc.) makes the use case distinct.

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

• sheet_graphA
  4.7/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure — and it fully delivers. It reveals observable behavior well beyond the schema: caching and build-once semantics ('Built once per document from the text layer and cached'), atomic availability ('unavailable, never half-populated'), the exact pixel-vs-point coordinate system ('PDF pt × 2, origin top-left, y down'), and the way it treats table continuation and rotated headers. This is exactly the kind of context annotations would otherwise need to carry.

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

  Conciseness2/5

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

  This is a dense run-on wall of text — about 250 words with heavy parenthetical nesting, ALL-CAPS emphasis, and em-dash on em-dash — with no bullet points or line breaks. Every sentence does add unique information, but the format makes it difficult for an agent to scan or parse. This is the description's one real weakness: thorough to the point of being overwhelming with zero visual hierarchy.

  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?

  Given the high complexity of this tool (a full plan-set index with sheets, schedules, rooms, unmatched tags, detail callouts, revision markers, and building designators) plus an available output schema that it complements rather than duplicates, the description is remarkably complete. It covers content, failure modes, coordinate spaces, caching semantics, and pipeline position — leaving virtually no question about what the agent receives or when the tool is appropriate.

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

  Parameters5/5

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

  With zero parameters, the baseline is 4 per calibration; the description goes well beyond the baseline by thoroughly documenting the rich return structure an agent must understand — including the shape of 'corroboration', the 'unmatched_tags' array with reasons, and the revision markers. Since there are no parameters to document, the tool's entire semantic weight is in its output, and the description maps that out completely.

  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?

  The description is unambiguous about what this tool is: 'The plan-set INDEX (#87): every sheet's role (plan / schedule / legend...)' — a specific noun (index) with an enumerated scope (sheet roles, schedule tables, rooms, unmatched tags, revisions). It clearly distinguishes itself from siblings by positioning itself as the read/preparation step: 'This is how an agent decides WHAT to measure without a human enumerating the rooms.' The scope and resource are specific and concrete, not a restatement of the name.

  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?

  Explicit when-to-use and workflow guidance is provided: 'list the rooms here, resolve each with resolve_tag, then measure with one_click/detect_rooms.' The failure case is explicitly governed ('A scanned set (no text layer) returns available: false — unavailable, never half-populated'), and the warning to 'READ those reasons, one of them may be a room the schedule left out' gives the agent a concrete decision aid. Alternative sibling tools (resolve_tag, one_click/detect_rooms) are named directly.

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

• derive_baseA
  4.8/5.0
  Behavior5/5

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

  No annotations are provided, so the description must fully disclose behavior. It does: commits one shape per room, records the claim on origin.derived (from_shape_id, gross_lf, openings_lf), never guesses, all-or-nothing atomicity, one undo step, and refusal to derive onto source condition. This is exceptionally transparent and leaves no ambiguity about side effects.

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

  Conciseness5/5

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

  The description is dense but every sentence earns its place. It front-loads the core purpose and formula, then methodically covers workflow, data recording, validation, undo behavior, and constraints. There is no fluff or repetition; the structure mirrors the natural sequence of using the tool.

  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?

  For a complex tool with 3 parameters, no annotations, and an output schema (not shown), the description is highly complete. It covers the full lifecycle: prerequisites (committed rooms), input specification (openings per room), side effects (commit, recording on origin.derived), failure modes (all-or-nothing refusal), and constraints (own tag). Nothing necessary is missing.

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

  Parameters5/5

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

  Despite 100% schema coverage, the description adds significant meaning beyond the schema: it explains how to stack openings by repeating shape_id, states that openings meeting a room's whole perimeter are refused, and clarifies the 'claim' semantics (your claim to make, recorded on origin.derived). This enriches the raw parameter definitions substantially.

  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?

  The description precisely states the tool's function: 'Mint the wall base from committed rooms (#148)' with a clear formula (base LF = room perimeter − stated door openings) and details that it commits one linear shape per room. This distinguishes it from sibling tools like measure_polygon or list_shapes by emphasizing the derivation/commit workflow and the 'base lands on its own tag' behavior.

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

  Usage Guidelines4/5

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

  The description provides clear workflow context: use view_sheet to inspect doors, then state openings per room. It also states when not to use it (deriving onto the source condition is refused) and describes all-or-nothing validation. However, it doesn't explicitly name alternative tools for manual measurement or other derivation types, so it stops short of full when/when-not guidance.

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

• derive_transitionsA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and goes far beyond it: it discloses all-or-nothing atomicity ('refuses the whole call before anything commits'), the single-undo-step behavior, the committed vs. withheld output split, coordinate system specifics (image px at scale 2.0, origin top-left, y down), and failure conditions. It also explains the critical geometric nuance that flood-traced rooms do not share edges, which materially affects what the tool returns.

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

  Conciseness5/5

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

  The description is long, but every paragraph earns its place for a tool with complex geometric behavior. It opens with a one-sentence purpose, then systematically covers geometry, tuning, failure modes, and post-conditions. The structure uses clear signposts ('WHAT THE GEOMETRY ACTUALLY IS', 'Tuning:', 'All-or-nothing') to make the length navigable.

  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?

  The description is remarkably complete for a complex tool, covering input semantics, output semantics (committed vs. withheld, total_lf), coordinate system, failure conditions, undo behavior, and recommended follow-up actions. Since an output schema exists, it doesn't need to enumerate return fields, but it still explains the meaning of those fields and the operational context, exceeding the minimum needed.

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

  Parameters5/5

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

  Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: it explains that condition is 'minted on first use', elaborates on max_gap_in's trade-off ('Wider only produces more wall_separated QUESTIONS, never more committed LF'), clarifies min_run_in as a corner artifact filter, and contextualizes condition_a/condition_b with examples. This is exactly the kind of semantic enrichment that helps an agent choose correct parameter values.

  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?

  The description opens by naming the exact operation: 'Mint the transition where two finishes MEET (#202)', which is specific and action-oriented. It also distinguishes itself from siblings by explicitly calling out that it 'follows derive_base' and by referencing the 'symbol_sweep doctrine' to differentiate its behavior from symbol_sweep.

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

  Usage Guidelines4/5

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

  The description clearly establishes when to use this tool—after derive_base, when two finish tags require a transition—and gives practical tuning guidance ('raise it for thick walls'). It also directs users to alternatives for follow-up actions ('view_sheet at `at`, then measure_line or place_count the threshold yourself'), but it does not provide explicit 'when not to use' exclusions, so it falls short of a 5.

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

• detect_roomsA
  4.8/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden. It discloses extensive behavioral traits: internal gates, withheld reasoning, merged_labels, 'never dropped silently', the same sealed engine, coordinate space, and commit requirements. It also clarifies confidence as a review prioritizer, not verification.

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

  Conciseness3/5

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

  The description is an extremely long, single paragraph with many parentheticals and rhetorical asides (e.g., 'double-counting an area is the worst failure'). Although front-loaded with purpose, it is not appropriately sized; each sentence does not strictly earn its place due to verbose explanatory philosophizing.

  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?

  For a complex tool with 8 params, nested layers, and output schema, the description covers input source, detection process, error handling, commit semantics, scale dependence, post-commit audit, and output coordinates. Output schema handles return values, so no gap in completeness.

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

  Parameters5/5

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

  Even with 75% schema coverage, the description adds significant meaning beyond the schema: role 'deduct' makes them subtract, min_area_sf plausibility floor, sensitivity usage, assign_from_schedule vs condition mutual exclusivity, and scale requirement for sheet. It compensates for missing schema descriptions and enriches parameter understanding.

  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?

  The description opens with 'Batch room detection: reads every room-number label off the sheet's text layer' and explicitly contrasts with 'read_sheet_text + reasoning + N one_click calls', clearly distinguishing it from siblings. The verb+resource+scope is specific and immediately clear.

  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?

  It gives explicit when-to-use guidance: 'when a schedule exists in the set, THIS is the default move' vs condition, and notes 'Without a scale... commits nothing'. It also instructs to audit with view_sheet and fix misses, providing clear context for use cases and exclusions.

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

• edit_shapeA
  4.8/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that quantities are recomputed from the result, that a role flip alone re-measures, that human-affirmed shapes are refused, and that agent self-revision is tallied separately. It also specifies the coordinate system (image px at render scale 2.0, origin top-left, y down), which is critical for correct usage.

  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?

  The description is dense and front-loaded: purpose, parameter summary, workflow, constraints, and coordinate system are arranged logically. The label reporting seam paragraph is lengthy and somewhat complex, but every sentence adds meaningful context, so the length is justified.

  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?

  Given 5 parameters, no annotations, and the existence of an output schema, the description explains the tool's role in a broader lifecycle, the refusal rule, recalculation behavior, and coordinate semantics. It could mention the no-op case for sending only shape_id, but the description is otherwise comprehensive and complete.

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

  Parameters4/5

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

  Schema coverage is 100% so the baseline is 3; the description adds value by mapping parameters to actions, e.g., 'verts to move the geometry', 'condition to reassign it to a different finish tag', 'role to switch...', 'label to name the room'. However, it only lists floor_area/deduct/linear in the prose and omits the surface_area and count role options (which are only in the schema enum), and the coordinate detail is helpful but not essential beyond the schema.

  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?

  The description opens with 'REVISE a shape you already committed' — a specific verb and resource — and enumerates the exact modifications supported: verts, condition, role, label. It explicitly contrasts with the alternative of deleting and starting over, and clearly distinguishes from sibling tools like measure_polygon and delete_shape.

  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?

  It provides an explicit workflow loop: 'one_click or measure_polygon to commit, view_sheet with overlay:true to LOOK at what landed, then edit_shape to fix...'. It also states a strict exclusion rule: 'Shapes a human affirmed (origin.reviewed) are ink and are refused — an agent revises its own pencil and nothing else.' This gives clear when-to-use and when-not-to-use guidance.

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

• list_annotationsA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses critical behavior: coordinate transformation (image px at render scale 2.0, PDF pt × 2, origin top-left, y down), resolution of condition_id to finish tags, and the semantics of 'unattached' and 'verdicts'. This goes far beyond basic expectations.

  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?

  The description is dense but every sentence carries necessary behavioral detail. It efficiently covers output fields, filters, and coordinate system without redundancy. Slightly long, but the complexity of information justifies the length.

  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?

  For a tool with no annotations and complex output behavior, the description covers all essential aspects: filters, coordinate system, resolved condition semantics, and the purpose of special fields. An output schema exists, so not explaining every return field is acceptable; the description still adds enough context to use the tool correctly.

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

  Parameters4/5

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

  Schema descriptions already cover both parameters (100% coverage). The description adds meaning by clarifying that filters can be combined ('or both'), and explicitly maps the 'condition' parameter to the resolved finish tag concept, which is not fully apparent from the schema alone.

  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?

  The description clearly states the tool lists every annotation on the takeoff with condition_id resolved to its finish tag. It distinguishes itself from siblings by mentioning resolved conditions, unattached counts, and verdicts, which positions it as the comprehensive annotation inventory tool.

  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?

  Explicitly explains filtering by sheet, condition, or both, and ties output fields to concrete actions: 'unattached' identifies candidates for link_annotation, and 'verdicts' serves the mark_verdict/delete_verdict family. This provides clear when-to-use guidance versus related tools.

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

• sheet_contextA
  4.8/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 excels: it details decimation ordering (longest-first, whole segments drop), the meaning of has_vector_linework:false, coordinate space, and the non-mutating nature ('exposed as data instead of pixels'). It also accounts for reconciliation of kept/dropped counts, leaving no ambiguity about side effects or edge behavior.

  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?

  The description is long but dense, with each sentence adding unique information about decimation, coordinate systems, or usage. It is slightly repetitive about image px and top-left origin, but this emphasis is justified given how often coordinate mistakes cause errors. No filler or tautology.

  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?

  The description fully covers what the tool returns, how decimation works, how the output relates to view_sheet, and the semantics of hatch IDs. Given the complexity (three data types, coordinate conversion, decimation policy), it leaves no significant gaps for an agent 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.

  Parameters4/5

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

  The schema covers 75% of parameters, and the description adds semantic depth beyond the schema: it explains that min_len_px default corresponds to one point at render scale 2.0, and that max_segments cap is applied 'longest-first' so walls survive. This complements the schema's terse descriptions, though the schema already provides solid baseline coverage.

  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?

  The description clearly states the tool returns structural data (classified vector segments, positioned text spans, hatch-family instances) for a region, distinguishing it from rendering tools like view_sheet. The resource and scope are specific, and the emphasis on the integrated response makes the purpose unambiguous.

  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?

  It explicitly says 'Use it when you need to REASON about a region rather than look at it' and mentions view_sheet as the counterpart for visual rendering. It also provides a concrete usage pattern (matching plan regions to legend swatches via hatch IDs), leaving no doubt about when to apply this tool.

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

• symbol_sweepA
  4.8/5.0
  Behavior5/5

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

  With zero annotations, the description carries the full disclosure burden and fully satisfies it: internal watch-scores (0.92 vs 0.75–0.92 band), the floor-when-complete-false semantic, the hard work ceiling, the one-undo-step batch commit behavior, refusal cases, the coordinate system, and the scale-resize/scale-assumed report. There is no hidden behavior an agent would learn only after a risky experiment.

  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?

  The first sentence front-loads the primary purpose and the rest organizes by theme (scope, scale, commit, exclude, luminance, labels, coordinates) — every sentence carries a distinct fact. The description is very long, organized in long unbroken paragraphs rather than compact sections, so a scanning agent must read a large block to extract the key thresholds. Length is proportionate to the tool's real complexity, so this is fair rather than a defect.

  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?

  For a tool with 11 parameters, special scoping and disclaimers, the description plus an output schema covers everything: the threshold semantics, the floor-vs-total disambiguation, refusals, scale handling, exclusion disclosure, the commit/undo guarantee, and coordinates in both px and pt. An agent has everything needed to call this tool correctly even in binary sheet-scale edge cases.

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

  Parameters4/5

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

  Schema coverage is 100%, which sets the description-bar baseline at 3, but the shared vocabulary goes beyond it: it prescribes 'tight seed_rect around a single instance' and explains the fully-inside-are-seed behavioral, the empty-rect exclusion mechanic, the commit_seed sheet-only-#296 rule, and the concrete 32–64 luminance band as a semantic key for black-vs-grey stroke separation. Not a 5 because the schema already documents each parameter accurately and the extra value is refinement, not basic understanding.

  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?

  The description opens with a specific verb+resource statement: 'Find EVERY instance of a repeated plan symbol from ONE example', then names the matching mechanism (deterministic geometry, not vision), the scope modes (sheet/set), and the score threshold. It also distinguishes itself from the sibling manual counter place_count by stating it uses 'the same path' only for the commit step.

  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 when-to-use and when-not-to-use guidance: a detail/legend/schedule seed is refused until both scales are set, a missing scale degrades to a disclosed 1:1 run, and the 'complete false' branch tells the agent to tighten the seed rather than trust the count as a total. It also routes to more specific alternatives like place_count for reinstatement and view_sheet for LOOKING at WITHHELD and exclusion candidates.

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

• undo_lastA
  4.8/5.0
  Behavior5/5

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

  With no annotations present, the description carries full burden and excels: it discloses the journaling model ('reads are never journaled, so n counts gestures that changed something'), reveals the exactness guarantee per mutation type (restored verbatim, re-inserted, array restored, pair restored), and disclaims approximation ('restores state rather than approximating it'). For a session-internal undo, omitted details like auth or rate limits are not applicable, and there is no contradiction with structured data.

  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?

  There is no dead weight — every sentence carries semantic load, and scoping comes first. However, the opening sentence is a run-on that buries the type enumeration in a long parenthetical, and the emphatic 'your OWN' adds tone without information. A judicious trim (~30%) would make it tighter, but this is well above average.

  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?

  Given zero annotations and the inherent complexity of an undo-with-journaling semantics, the description covers semantics, scope, state-reset triggers (load_plan), and usage signals. The presence of an output schema removes the need to document return values, and the only genuine gap — behavior on an empty history — is a minor edge case.

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

  Parameters4/5

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

  Schema coverage is 100% (n: integer, 1–100, default 1), so the baseline is 3 even with no extra description. The description earns the bump by clarifying what n actually counts ('gestures that changed something, not tool calls you made') and hinting at batching via 'one call instead of N deletes.' It doesn't reach 5 because the schema already handled the mechanics.

  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 clear verb+resource+scope ('Step back over your OWN last n mutations, newest first') in the very first phrase, so an agent immediately knows what it does. It explicitly differentiates itself from a likely source of confusion ('It is not the browser canvas's undo stack') and grounds every example type (one_click, detect_rooms, edit_shape...) in actual sibling tools, making the purpose unambiguous.

  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?

  Provides concrete trigger scenarios ('a sweep committed against the wrong condition or a batch went in on the wrong sheet') with an economics argument for choosing it ('one call instead of N deletes'). Explicitly scopes itself away from alternatives: not the browser canvas undo, session-only history, and invalidated by load_plan. This is exactly the when/when-not guidance the rubric asks for.

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

• count_marksA
  4.9/5.0
  Behavior5/5

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

  Since no annotations are provided, the description fully carries the burden of behavioral disclosure. It explains deterministic behavior (no seeds, no model), counting rules (tags paired with values count, schedule table row labels are excluded), withholding logic with reasons, coordinate system (image px at render scale 2.0), commit behavior (one undo step), and audit steps. This exceeds minimal transparency expectations.

  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?

  The description is verbose but every sentence contributes value—covering counting rules, exclusions, refusal conditions, coordinate systems, and audit instructions. It is front-loaded with the primary purpose and flows logically through usage, behavior, and parameters. While not ultra-concise, the density justifies the length; a 4 reflects that it could be tightened without losing critical information.

  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?

  The description is complete for an agent to invoke the tool correctly. It covers what counts, what's excluded, refusal scenarios, coordinate systems for marker placement, commit semantics, and follow-up audit steps. Given the presence of an output schema (not detailed here) and the complexity of the tool, the description leaves no critical gaps an agent would need to call it correctly.

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

  Parameters5/5

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

  Although the schema includes descriptions for both parameters (marks and commit), the tool description adds substantial meaning. It explains the default behavior for marks (taken from schedule row keys), how compound rows answer for multiple marks, and clarifies that commit commits every counted occurrence under its mark. This enriches the schema guidance, providing deeper semantic context than the schema alone.

  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?

  The description clearly states the tool's purpose: it 'census every VALUE-ANNOTATED mark tag' and counts per schedule mark, distinguishing it from sibling tools like sweep_schedule_row. The verb 'census' and resource 'value-annotated mark tags' are specific and actionable, making it immediately clear what the tool does and how it differs from alternatives.

  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?

  The description explicitly contrasts with sweep_schedule_row, explaining that this tool is for annotated devices with values, while the sibling is for marks without values. It also clarifies when to provide explicit marks versus relying on defaults from schedule row keys, and notes refusal conditions (no text layer, no mark-shaped rows). This gives the agent clear guidance on when to use this tool versus others.

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

• cut_outA
  4.9/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden, and it delivers richly: it explains the boolean-subtract mechanism, composition of cuts, set subtraction preventing double-deduct, perimeter additions, journaling behavior (undo_last restores parent and hole together), and the reversal via delete_shape. It also discloses coordinate conventions and run-clipping behavior, giving an agent deep insight into the tool's side effects and constraints.

  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?

  The description is quite long, but every sentence carries technical nuance essential for correct invocation, such as composition rules, journaling, and refusal conditions. It is front-loaded with the core purpose, though the parenthetical references (#206, #137) and some repetition about runs could be trimmed without losing meaning. Minor over-verbosity prevents a 5.

  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?

  Given the tool's complexity, no annotations, and an existing output schema, the description is remarkably complete. It covers all invocation parameters, coordinate systems, behavioral rules, edge cases, and refusal conditions, so an agent can correctly determine when and how to call it without needing external information.

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

  Parameters5/5

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

  While the schema covers both parameters, the description adds substantial meaning: verts are specified as image px at render scale 2.0 with origin top-left, y down, and parent_shape_id can be either a committed floor_area or an open run. It also explains how the ring interacts with runs (clipped, not subtracted) and lists refusal scenarios, going well beyond the schema's short descriptions.

  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?

  The description states a specific verb and resource: 'Cut a REAL hole in a committed floor_area shape' and explicitly contrasts with measure_polygon's 'deduct' role for deductions that are not holes in a parent. It also distinguishes from edit_shape for edge-crossing boundary corrections. This makes the tool's purpose unambiguous and separates it from siblings.

  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?

  The description explicitly states when to use this tool: for a column, floor drain, or island of casework inside a room; and when to use alternatives: measure_polygon role 'deduct' for independent deductions, edit_shape for boundary corrections, and delete_shape for cuts that swallow a run whole. It also covers the clipped-run case and refusal conditions, providing clear routing guidance.

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

• find_scheduleA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and excels. It discloses how schedules are matched (including continued schedules as one match with parts), handling of rotated headers, building-specific tables, revised rows, and coordinate system details (px at render scale 2.0, origin top-left, y down). Error messages are explained, and sheet payload dimensions are mentioned. This is highly transparent.

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

  Conciseness5/5

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

  The description is long but densely packed with essential information. It front-loads the main purpose and then systematically covers edge cases and technical details. Every sentence adds value—no filler or repetition. The structure is logical and efficient.

  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?

  Given the tool's complexity and the presence of an output schema, the description is complete. It explains the result structure (parts, building, revised_rows), error handling, coordinate system, and sheet payload dimensions. No critical aspect is missing; users know exactly what to expect and how to use the tool.

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

  Parameters4/5

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

  Schema coverage is 100% for the single 'kind' parameter, so baseline is 3. The description adds contextual meaning: it explains that 'room finish' corresponds to rooms→surface finishes and 'finish'/'material' to codes→products, and connects the parameter to the tool's overall purpose. This extra explanation justifies a 4, though the schema already covers the literal values.

  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?

  The description clearly states the tool's purpose: to locate schedule tables in a set by passing a kind, and it lists exactly what information is returned (sheet, title, headers, TOTAL row count, REGION). It distinguishes from siblings by referencing view_sheet and read_sheet_text usage and detailing edge cases (multi-sheet schedules, rotated headers, building-specific tables). This is specific and unambiguous.

  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?

  The description explicitly explains when to use the tool: to find schedules for viewing or reading. It explains the 'kind' parameter choices and their meanings ('room finish' vs 'finish'/'material'), and describes the output structure that guides downstream actions. It also covers error behavior when the kind isn't found, giving clear expectations.

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

• load_planA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels: it discloses the destructive default (clears session), the merge behavior, the refusal condition, the return payload, coordinate system details, and the conversion to browsable resources. This is a comprehensive safety/behavioral profile.

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

  Conciseness5/5

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

  The description is a single dense paragraph but logically organized: action, default behavior, merge variant, edge case, return values, resources, and coordinate system. Every sentence adds necessary information with no filler, achieving conciseness through purposeful density.

  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?

  Given the tool's moderate complexity and absence of annotations, the description covers everything an agent needs: the two modes, re-load restriction, return fields, coordinate transformation, and resource availability. It is fully sufficient for correct invocation and interpretation.

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

  Parameters4/5

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

  The schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds meaningful context beyond the schema by elaborating on the default behavior, the meaning of merge:true, and the edge case of merging into an empty session, increasing clarity for parameter usage.

  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?

  The description opens with a clear verb+resource ('Open a plan PDF from disk') and immediately clarifies the default replacement behavior versus merge mode. This distinguishes it from sibling tools that operate on already-loaded sheets or produce analyses.

  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?

  It explicitly contrasts the default replace-all behavior with merge:true for adding to a working set, explains the bid-set use case, and states that re-loading an already-merged file is refused. This gives clear when-to-use and when-not-to-use guidance, including a concrete scenario.

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

• annotateA
  5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full responsibility for disclosing behavior, and it does so richly. It reveals the no-review-gate policy and the pencil-not-ink rationale, the coordinate system ('image px at render scale 2.0: PDF pt × 2, origin top-left, y down'), the scale-gate refusal for dimensions on unscaled sheets, and tag minting on first touch. This goes far beyond typical descriptions.

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

  Conciseness5/5

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

  The description is long but every sentence is purposeful: it covers the core purpose, each annotation type's specific parameters, behavior under scale gate, condition attachment semantics, and coordinate conventions. It is front-loaded with the main purpose and progressively adds detail in a logical flow. No redundancy or filler.

  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?

  Given the complexity of 7 annotation types, 10 parameters, and interaction with scale/condition/review gates, this description is remarkably complete. It addresses all parameter roles, edge cases (unscaled dimension refusal, tag minting, condition color), coordinate system, and the tool's relationship to quantity takeoff. An output schema exists, so return values need not be spelled out, and the description is sufficient for correct invocation.

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

  Parameters5/5

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

  Despite 100% schema coverage, the description adds substantial meaning beyond the raw schema. It explains the geometric roles of rect for cloud/highlight, target for callout, from/to for arrow and dimension, and at for text/callout/bubble. It also clarifies that dimension labels itself with the measured length and appends text after it, which is not evident from the schema alone. This elevates the semantics significantly.

  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?

  The description opens with a clear verb and resource: 'Place an annotation on a sheet' and immediately distinguishes its purpose: 'a note ABOUT the work, never a measurement of it.' This contrasts with sibling measurement tools like measure_line and measure_surface. It also enumerates the specific annotation types, leaving no ambiguity about what the tool produces.

  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?

  The description provides explicit when-to-use guidance: annotations are for notes, not measurements, and the dimension type is singled out as the one annotation subject to the scale gate, with instructions to set_scale first. It also explains when to omit condition ('for a note about the sheet itself') and how condition attachment ties to a finish tag, referencing sibling tools like one_click/measure_polygon for tag minting. This gives clear decision support.

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

• duplicate_conditionA
  5/5.0
  Behavior5/5

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

  Despite no annotations, the description thoroughly discloses behavioral traits: the inheritance propagation rule ('change a coverage rate on the original and every twin that has not touched that row gets it'), the label uniqueness requirement with rationale (first match wins, duplicate tags cause unreachable conditions), refusal of duplicate labels, and reversibility. This far exceeds a simple 'duplicates a condition'.

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

  Conciseness5/5

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

  The description is lengthy but every sentence provides valuable information, covering concept, examples, constraints, and alternatives. It is logically structured, starting with core purpose and layering detail, with no redundant or filler content.

  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?

  It addresses why the tool exists, the inheritance behavior, labeling pitfalls, what is not carried over ('No takeoffs come along'), and how to reverse the action. It also indicates the return value (condition_id) and is complemented by an output schema, making it complete for a complex tool.

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

  Parameters5/5

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

  While the schema defines 'label' and 'condition' with brief descriptions, the description adds critical semantics: label becomes a tag suffix with a concrete example ('CPT-1' + 'Level 2' → 'CPT-1 – Level 2') and must be unique. It also clarifies that condition is the finish tag the twin follows, providing much deeper meaning than the schema alone.

  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?

  The description opens with 'Twin a condition — the same finish measured somewhere else, with its own supporting materials,' providing a specific verb and resource. It clearly distinguishes from siblings like split_condition, which ends inheritance, and edit_condition, which modifies a condition.

  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?

  It gives a concrete scenario for when to use the tool ('One finish in two areas... same sheet goods over a slab and over a raised deck...') and explicitly names alternatives: 'Reversible with undo_last; use split_condition to end the inheritance permanently.' It also instructs the user to 'measure the new area against the returned condition_id,' guiding post-invocation steps.

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

• edit_conditionA
  5/5.0
  Behavior5/5

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

  With no annotations, the description fully carries the behavioral transparency burden. It discloses downstream effects (takeoff_summary emits waste-adjusted *_net quantities, exports carry both), error behavior on typo'd tags, roll_setup presence as opt-in with null opt-out, reply echoing figured orders, and undo_last reversing with a snapshot. No contradiction with structured data.

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

  Conciseness5/5

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

  The description is long but every sentence carries value. It is front-loaded with the primary purpose, then elaborates on each parameter, edge cases, and interactions. Examples like 'carpet commonly 5–10' and issue references add specificity without padding.

  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?

  It covers prerequisites, side effects, output behavior (reply echoes figured order), interaction with undo_last, and roll_setup nested options. Even with an output schema present, the description provides essential context about when and how quantities are applied, making it comprehensive for an agent.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds significant semantic meaning: waste_pct is the estimator's cut-waste percentage (carpet 5-10), multiplier scales before waste, height_ft is the H knob measure_surface quantifies against, and roll_setup presence is opt-in with partial edits patching the existing setup. This goes far beyond the raw schema descriptions.

  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?

  The description opens with 'Set a condition's quantity knobs' and enumerates the specific knobs (waste %, multiplier, height_ft, roll_setup), clearly identifying the resource and action. It also distinguishes from siblings like edit_materials by referencing its remove/patch rule and from measure tools by noting the default starting values.

  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?

  It explicitly states when to use the tool: after measuring, to adjust quantity knobs that otherwise default to waste 0/multiplier 1, making takeoff net===gross. It also provides prerequisites (condition must resolve to an existing finish tag) and mentions alternatives like undo_last for reversal and contrasts with edit_materials add rule.

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

• edit_materialsA
  5/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and delivers: it discloses the no-review-gate direct edit behavior, whole-call 404 on bad ids, the error on missing condition, and the seam_lf reading 0 without roll_setup. It even includes a concrete example (20-ft vs 10-ft rooms) to explain the figured basis.

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

  Conciseness5/5

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

  The description is long but every sentence earns its place: it packs the purpose, formula, edge cases, error behavior, and tool relationships into one dense paragraph that is front-loaded with the action verb.

  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?

  Given the tool's complexity (add/remove/patch with six fields and a special basis), the description is remarkably complete: it covers formulas, edge cases, failure modes, and integration with edit_condition, undo_last, and export_takeoff. With an output schema present, return values need no explanation.

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

  Parameters5/5

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

  Although the schema already covers all parameters at 100%, the description adds the calculation formula (basis ÷ per, rounded up), the meaning of round:false, the seam_lf special handling, and the minting of new tags on condition. This significantly enriches parameter understanding beyond the schema.

  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?

  The description opens with a specific verb phrase 'Add, remove, or patch supporting-materials rows' and grounds the tool in the 'per-condition Supporting Materials panel,' clearly distinguishing it from sibling tools like edit_condition and takeoff_summary. It also explains the row structure and calculation, leaving no ambiguity about what the tool does.

  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?

  The description provides explicit context on when to use the tool: it is for 'quantity config, not traced geometry' and notes that undo_last reverses a call. It also contrasts with takeoff_summary ('strips materials') and directs users to edit_condition for roll_setup, making the relationship to alternatives clear.

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

• mark_verdictA
  5/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It details side effects (provenance recording, glyph anchor persists even if shape deleted), non-effects (touches no quantity, gates nothing), rendering behavior, tally in marked-set, payload propagation, and coordinate conventions. It also explains the one-mark-per-shape rule and interaction with undo_last. This is exemplary transparency.

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

  Conciseness5/5

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

  The description is long but every sentence contributes unique, essential information. It is front-loaded with purpose, then systematically covers targeting, behavior, rendering, and coordinates. No filler or repetition; efficient for the tool's complexity.

  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?

  Given the tool's moderate complexity, the description is remarkably complete. It covers all parameters, behavioral nuances, sibling relationships, coordinate systems, and lifecycle interactions (re-mark, undo, list). The output schema exists, so not describing return values is acceptable. There are no significant gaps.

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

  Parameters5/5

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

  Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It clarifies the mutually exclusive targeting modes (shape_id vs sheet+at), the coordinate system (image px at render scale 2.0, top-left origin, y down), and the exact role of text. This significantly enriches parameter understanding.

  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?

  The description opens with a clear, specific verb+resource ('Mark the agent's VERDICT on work') and immediately distinguishes this tool from the estimator's approval ring, identifying it as the only half an agent can mint. It explicitly states what the tool does and how it differs from siblings like delete_verdict and annotate.

  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?

  The description provides explicit when-to-use guidance: it distinguishes the two targeting modes (shape_id vs sheet+at) and states 'Exactly one target.' It also mentions alternatives such as delete_verdict for re-marking and list_annotations for inventory, and clarifies that this is the agent's tool distinct from the estimator's approval. This exceeds basic usage guidance.

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

• view_sheetA
  5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral load. It discloses the 2000-px long-side limit, the coordinate mapping formula, the visual semantics of overlay (solid vs dashed, colors), the grid's meaning (1-ft/5-ft lines, labels), the marks meaning (colors and shapes), and the dependency on a native canvas module with graceful degradation. It also warns about render precision and how to verify geometry.

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

  Conciseness5/5

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

  Though long, the description is dense and every sentence carries essential guidance. It is front-loaded with the core purpose and crop guidance, then proceeds logically through coordinate mapping, overlay, grid, marks, and canvas dependency. No fluff; each clause earns its place.

  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?

  With no output schema, the description fully explains return behavior (image, pixel coordinate mapping), all parameter effects (grid, overlay, marks), the required canvas dependency with failure mode, and a coordinate conversion formula. The only minor omission is an explicit statement of return type, but it is clearly implied by 'returns a PNG image' and the coordinate discussion. Complete for an agent to call correctly.

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

  Parameters5/5

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

  Every parameter is explained well beyond the schema's one-liners: region is defined as image px and the coordinate mapping formula is given; grid specifies feet counts and colors; overlay explains solid vs dashed and their meaning; marks details each visual symbol and its purpose. The description makes each parameter operationally clear.

  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?

  The description opens with a clear verb and resource: 'SEE the page (or a crop of it) as a PNG image.' It immediately distinguishes itself from sibling tools by explaining that it is the visual counterpart to measure_polygon and read_sheet_text, and it gives concrete use cases (locating vs reading details). Purpose is unmistakable.

  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?

  Usage guidance is explicit and actionable: full-sheet renders for orientation, tight crops for reading linework/dimensions, and a precise warning never to audit a trace or read a dimension off a full-sheet render. It also tells the agent when to re-render with overlay:true to verify geometry and how to use grid for measurement. Alternatives are named directly (measure_polygon, read_sheet_text, one_click).

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