opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

count_marks

Census every value-annotated mark tag on plan-role sheets, count occurrences per schedule mark, and optionally commit them as EA markers in one step.

Instructions

The COUNT TAKEOFF in one deterministic call — no seeds, no model, seconds: census every VALUE-ANNOTATED mark tag on the plan-role sheets, counted per schedule mark, committed as EA markers when asked. The identity rule is the annotated-device drafting pattern: a device is drawn as its mark tag with a value under it ("S1" over "200" — CFM on air devices, GPM on fixtures, a rating on equipment), so a tag WITH a paired value counts, a tag inside a schedule table's own region is a row label (excluded, tallied), and every other occurrence is WITHHELD with a reason and coordinates — a tag amid linework but unvalued may be a real device (view_sheet it), a bare tag is probably a note mention. Marks default to the set's schedule row keys (a compound row "R1 / E1" answers for R1 AND E1; each mark cites its row), or state them: {marks: ["S1","R1"]}. The complement to sweep_schedule_row: THAT tool is for marks drawn ON their marker with no value (finish tags in bubbles) and matches geometry; this one is for annotated devices and needs no fingerprint at all. Refusal-honest: scans refuse (no text layer), a set with no mark-shaped rows refuses unless marks are stated, non-plan sheets are skipped with the role that excused them. commit: true commits every counted occurrence under its mark's own tag — ONE undo step for the whole census, schedule citation on origin. Counts are scale-free (EA) — no set_scale needed. Then AUDIT: view_sheet {overlay: true} where the markers landed, and read every withheld entry — a withheld item you ignore is a hole in the bid. Coordinates are image px at render scale 2.0: PDF pt × 2, origin top-left, y down (the browser canvas's native space). Sheet payloads carry dims in both px and pt. EQUIPMENT marks (a row in an equipment/device schedule — fans, pumps, heaters, fixtures, panels) follow the leader-tag convention instead: a scheduled mark drawn amid linework with no value under it is counted BY LABEL (occurrence by: "label", counted_by_label on the mark); a bare mention in a note still withholds.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`marks`	No	The marks to census, e.g. ["S1", "R1"] — omit to take them from the schedule tables' row keys
`commit`	No	Commit every counted occurrence as one EA count marker under its mark (withheld/excluded never commit)

Output Schema

TableJSON Schema

Name	Required	Description
`marks`	Yes
`total`	Yes	All counted instances across every mark
`skipped`	Yes
`complete`	Yes
`per_sheet`	Yes
`excluded_in_tables`	No	Tag occurrences inside a schedule table's own region — row labels, never instances

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.1.21Sep 12, 2026

changedOutput schema / properties / marks / items / properties / count / description

Previous value: -"Value-paired instances counted on plan-role sheets"New value: +"Instances counted on plan-role sheets — value-paired tags, plus (for an equipment-schedule mark) tags drawn amid linework, see counted_by_label"

addedOutput schema / properties / marks / items / properties / counted_by_label

Added value: +{
+  "description": "…of which counted by label (an equipment mark with a leader, no value under it)",
+  "type": "integer"
+}

addedOutput schema / properties / marks / items / properties / occurrences / items / properties / by

Added value: +{
+  "description": "\"value\" = tag-over-value (air devices, fixtures); \"label\" = an EQUIPMENT-schedule mark drawn amid linework with no value — the leader-tag convention, counted as one instance and said so",
+  "enum": [
+    "value",
+    "label"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / marks / items / properties / occurrences / items / properties / value / description

Previous value: -"The paired value drawn under the tag (CFM, GPM, a count — the annotation that makes it an instance)"New value: +"The paired value drawn under the tag (CFM, GPM, a count — the annotation that makes it an instance); absent when counted by label"

changedOutput schema / properties / marks / items / properties / occurrences / items / required

Previous value: -[
-  "at",
-  "value",
-  "sheet"
-]New value: +[
+  "at",
+  "sheet",
+  "by"
+]

Addedv0.1.19Aug 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

No annotations exist, so the description carries the full burden and does so richly: deterministic/no-seed behavior, the identity rule for what counts vs. is withheld, commit producing ONE undo step, refusal-honest scan/sheet behavior, and the coordinate space. This is far beyond what structured fields provide.

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?

Front-loaded with the core action, but the body is a dense run-on paragraph packed with jargon, heavy em-dash nesting, and a late equipment-marks addendum. Most sentences carry information, yet the structure makes it hard to parse and is longer than it needs to be.

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 needn't be explained, and the description still covers the counting rule, exclusions, refusals, commit/undo, coordinate frame, and the special equipment-mark case. Nothing an agent needs to call this correctly is missing.

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, but the description adds real semantics: how marks default to schedule row keys, compound-row behavior ('R1 / E1' answers for both), the citation of a source row, and the commit-per-mark semantics. This meaningfully exceeds the schema's own strings.

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

Purpose5/5

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

States a specific verb (census/count) and resource (VALUE-ANNOTATED mark tags per schedule mark) and names the sibling it is not (sweep_schedule_row). An agent can distinguish it from the geometry-matching alternative without opening either schema.

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 contrasts with sweep_schedule_row ('THAT tool is for marks drawn ON their marker with no value... this one is for annotated devices'), and states when marks should be stated vs. defaulted. Refusal conditions (scans, no mark-shaped rows, non-plan sheets) are spelled out.

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