Skip to main content
Glama
Sign In
opentakeoff-mcp

opentakeoff-mcp

by Kentucky-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

open_suite

Activates a construction trade suite by name or CSI division, revealing its measurement tools and returning method and condition names. Open only the trade you need; with no arguments it lists the catalog.

Instructions

Open a trade suite: enables that trade's tools (they are hidden until opened) and returns its method and condition names. Open only the trade you are taking off; opening is idempotent and never closes anything. No arguments = the catalog. Suites:

  • finishes (Div 09): flooring, base, transitions, wall finishes: core tools, no extra tools

  • roofing (Div 07): sloped roof area and squares, true rake/hip/valley LF, drip edge, starter, ridge cap, underlayment

  • siding (Div 07): net wall area and squares from elevations, opening trim, starter, corners, lap pieces

  • soffit_fascia (Div 07): soffit SF from eave/rake LF × depth, fascia LF, wall receiver, attic intake vent area

  • glazing (Div 08): storefront / curtain wall: frame SF, lites, glass SF, mullion LF, perimeter sealant

  • doors (Div 08): doors per type and size from the door schedule, matched to tags on the plans: core tools

  • plumbing (Div 22): fixture counts checked against the schedule QTY, pipe LF by system/size, hangers, fittings, insulation

  • electrical (Div 26/27/28): legend devices and fixtures counted, conduit LF with drops, wire LF by conductors, boxes, whips division opens every suite of a CSI division ("07" = roofing + siding + soffit_fascia).

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": "open_suite"
  }
}

Input Schema

NameRequiredDescriptionDefault
suiteNoSuite id
divisionNoCSI division, e.g. "07", "08", "22", "26"

Output Schema

NameRequiredDescriptionDefault
nextYes
openedYesSuites opened by this call (empty when listing)
suitesNoEach opened suite's method and condition presets
catalogNoEvery suite, one row each, when called without suite/division
open_suitesYes
tools_enabledYesTools that just became available

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.31

TDQS

A4.6/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 the hidden-until-opened gating model, idempotency, and the fact that opening never closes anything — the key non-destructive guarantee an agent needs. It does not state whether opened suites persist across sessions or reset, which is the remaining behavioral unknown.

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-loaded correctly: scope, side effect, and constraints land in the first two sentences before the catalog. The per-suite list is long but each line earns its place by telling the agent whether that suite covers its scope; slightly tighter phrasing would avoid the nested colons.

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?

An output schema exists, so return values need no elaboration, and the description still names them (method and condition names). For a zero-required-parameter gating tool, everything needed to decide which suite to open — and what opening does — is present.

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% and the enum already lists the eight suite ids, but the description adds real meaning by explaining what each suite measures (e.g. soffit_fascia = soffit SF from eave/rake LF × depth, fascia LF) and how `division` aggregates suites. This is genuinely beyond the schema's bare "Suite id" text, though the per-suite blurbs are terse rather than operational.

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 first sentence gives a specific verb and resource ("Open a trade suite") plus the concrete effect: it enables that trade's tools, which are hidden until opened, and returns its method and condition names. That distinguishes it cleanly from siblings like measure_surface or derive_base, which operate inside an already-open suite.

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?

"Open only the trade you are taking off" is an explicit positive rule, and "opening is idempotent and never closes anything" removes the main hesitation about repeat calls. "No arguments = the catalog" and "division opens every suite of a CSI division ('07' = roofing + siding + soffit_fascia)" make the two calling modes unambiguous.

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

Deploy Server

Other Tools