Skip to main content
Glama

count_marks

Counts value-annotated device mark tags on plan-role sheets per schedule mark and optionally commits them as EA markers, with excluded rows and withheld tags reported by reason and coordinates.

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "count_marks"
  }
}

Input Schema

NameRequiredDescriptionDefault
marksNoThe marks to census, e.g. ["S1", "R1"] — omit to take them from the schedule tables' row keys
commitNoCommit every counted occurrence as one EA count marker under its mark (withheld/excluded never commit)

Output Schema

NameRequiredDescriptionDefault
marksYes
totalYesAll counted instances across every mark
skippedYes
completeYes
per_sheetYes
excluded_in_tablesNoTag occurrences inside a schedule table's own region — row labels, never instances

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed20 schema fields changedv0.1.31
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / properties / excluded_in_tables / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / excluded_in_tables / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / marks / items / properties / committed / properties / committed / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / marks / items / properties / committed / properties / committed / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / marks / items / properties / count / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / marks / items / properties / count / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / marks / items / properties / counted_by_label / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / marks / items / properties / counted_by_label / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / marks / items / properties / occurrences / items / properties / at / additionalItems
      Added value: +false
    • addedOutput schema / properties / marks / items / properties / occurrences_elided / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / marks / items / properties / occurrences_elided / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / marks / items / properties / withheld / items / properties / at / additionalItems
      Added value: +false
    • addedOutput schema / properties / marks / items / properties / withheld_elided / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / marks / items / properties / withheld_elided / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / per_sheet / items / properties / counts / additionalProperties / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / per_sheet / items / properties / counts / additionalProperties / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / per_sheet / items / properties / counts / propertyNames
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / total / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / total / minimum
      Added value: +-9007199254740991
  2. Changed5 schema fields changedv0.1.21
    • 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"
      +]
  3. Addedv0.1.19

TDQS

A4.2/5.0
Behavior3/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 disclose a lot: three refusal conditions, skipped non-plan sheets with the excusing role, one-undo-step commit semantics, scale-free EA counts, and the pixel coordinate convention. However, it never states required preconditions such as loading a plan or having a schedule present, and the densely packed prose makes the refusal list easy to miss.

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

Conciseness4/5

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

Front-loads the core claim ('census every VALUE-ANNOTATED mark tag') and keeps the alternative-comparison and coordinates notes in a logical order. It is a wall of em-dash-clause prose with some filler ('no seeds, no model, seconds'), but almost every sentence carries operational information that would otherwise be missing.

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 a 2-param schema, the description covers what counts, what is excluded and tallied, what is withheld and why, the equipment/leader-tag exception, commit behavior, undo scope, coordinate space, and audit follow-up. Return values are legitimately omitted because an output schema exists.

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% and both parameters are documented in the schema, so the baseline applies. The description does add real meaning — that marks default to schedule row keys, that a compound row "R1 / E1" answers for both, and that commit: true yields a single undoable census with schedule citation on origin — but this is delivered as scattered narrative rather than ordered to the parameters themselves.

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

Purpose5/5

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

States a specific verb and resource — census VALUE-ANNOTATED mark tags on plan-role sheets, counted per schedule mark — and immediately names the identity rule (tag with paired value) that defines what counts. It explicitly contrasts itself with sweep_schedule_row, so an agent can pick between the two 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?

Gives explicit when-to-use (annotated devices, needs no fingerprint) versus when-not (tags drawn on their marker with no value, finish bubbles → use sweep_schedule_row), plus follow-up guidance to view_sheet for withheld items and view_sheet {overlay: true} to audit. That is routing, alternative naming, and a next-step procedure.

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