opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

place_count

Count markers such as thresholds, stair nosings, floor boxes, and entrance mats by placing scale-free EA points on a sheet, committing one count per point under a finish tag in a single undo step.

Instructions

Count markers — EA (#146): one point, one each. Thresholds, stair nosings, floor boxes, entrance mats — the scale-free quantity family. Commits one count shape per point (computed {count: 1}, exactly the canvas's Count tool), NO scale required, and the whole call is ONE undo step. takeoff_summary reports them as ea; the marked set draws each marker. 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sheet": "<sheet>",
      "points": "<points>",
      "condition": "<condition>"
    },
    "name": "place_count"
  }
}

Input Schema

Name	Required	Description
`sheet`	Yes
`points`	Yes	Marker positions (image px), one committed count shape each
`condition`	Yes	Finish tag to commit under (minted on first use), e.g. 'TR-1'

Output Schema

Name	Required	Description
`ea_total`	Yes	The condition's total EA after this call
`committed`	Yes	Count shapes committed by this call — one per point
`condition`	Yes
`shape_ids`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.1.31Nov 7, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / points / items / additionalItems
```
Added value: +false
```
- addedOutput schema / properties / committed / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / committed / minimum
```
Added value: +-9007199254740991
```
Addedv0.1.9Jul 31, 2026

TDQS

A3.7/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 does well: it discloses that each point commits one count shape, that the call is a single undo step, that the computed value is exactly {count: 1}, and that takeoff_summary reports results as 'ea'. It omits failure modes and any prerequisite/auth context, which keeps it from a 5.

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 lead sentence front-loads the core intent, but the body is dense with parentheticals, ticket references, and layered coordinate notes that slow parsing. Most content earns its place, but phrasing like 'exactly the canvas's Count tool' is redundant and the prose could be reorganized for faster scanning.

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 an output schema exists (return values need not be explained) and no annotations, the description covers the key behavioral traits: commit semantics, atomic undo, unit reporting, and the coordinate space. It leaves the `sheet` parameter's expected value and any boundary behavior on out-of-range points unaddressed.

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 67% and the description meaningfully extends it, especially for `points`: coordinates are image px at render scale 2.0 derived from PDF pt (×2), origin top-left, y down. It also reinforces that `condition` is minted on first use. The `sheet` parameter receives no added explanation, which is the one gap.

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?

States a concrete verb (place/count) and resource (markers) with the unit of work defined precisely: 'one point, one each' committing a computed {count: 1} shape. It scopes the tool to the 'scale-free quantity family' with concrete examples (thresholds, stair nosings, floor boxes, entrance mats). It does not name the nearest sibling (count_marks) to differentiate, so a 4 rather than 5.

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?

Usage is implied through the domain examples and the repeated 'NO scale required' emphasis, which signals when this is preferred over scaled measurement tools. However, it never explicitly says when not to use it or names an alternative sibling such as count_marks or measure_line, leaving routing to inference.

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

Deploy Server