Skip to main content
Glama

count_marks

Census value-annotated device mark tags on plan sheets, tallying counts by schedule mark and optionally committing each count as an EA takeoff marker.

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.

Input Schema

TableJSON 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

TableJSON 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
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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kentucky-ai/opentakeoff'

If you have feedback or need assistance with the MCP directory API, please join our Discord server