Skip to main content
Glama
roynertr

COBie MCP

by roynertr

capture_installation

Record equipment installation data in COBie workbooks during construction. Provide component identifier, installation date, serial number, status, and updater contact to update the file.

Instructions

Capture equipment installation data in the COBie workbook (construction phase).

**Before first use:** Call get_update_workflow() or get_actor_contact_schema() to get
the required actor_contact structure. Use MCP prompt 'how_to_update_cobie' for the full guide.

**IMPORTANT - File Modification Behavior:**
- **DEFAULT (output_path=None):** Edits the original file IN-PLACE (modifies excel_path directly)
- **With output_path:** Creates a NEW file at output_path, leaves original untouched
- **With create_backup=True:** Creates "excel_path.bak" backup before editing in-place

**Construction phase** (typical): Component name, type, and location are already in the
workbook from design. Only provide:
- component_identifier (required): The component name (e.g. "Tap-1", "DR:T1A")
- installation_date (optional): Use "today" or "now" when user says "just installed"
  **OR** use as_of_date parameter (if payload lacks installation_date, as_of_date is used automatically)
- serial_number, status (optional)
Do NOT ask for type, floor, or space—they are design-phase and already in the file.

**Payload fields:**
- component_identifier (required): Equipment name in the workbook
- installation_date (optional): ISO date, or "today"/"now" for current date.
  **NOTE:** If omitted and as_of_date parameter is provided, as_of_date will be used for InstallationDate.
- serial_number, status (optional): e.g. status="PLACED"|"STARTED"|"TESTED"|"COMMISSIONED"
- install_space, install_floor (optional): Only when adding NEW components; omit for
  construction phase—location comes from design.
- evidence_paths (optional): Paths to attach evidence files

**Actor contact (required):** Provide updater identity.
{
    "email": "john@example.com",
    "company": "ACME Corp",
    "phone": "555-1234",
    "category": "Installer"
}

**Minimal example (construction phase with as_of_date):**
{
    "payload": {
        "component_identifier": "Tap-1"
        # installation_date omitted - as_of_date will be used
    },
    "actor_contact": {
        "email": "installer@acme.com",
        "company": "ACME Corp",
        "phone": "555-1234",
        "category": "Installer"
    },
    "as_of_date": "2026-02-16"
}

**Alternative: explicit installation_date in payload:**
{
    "payload": {
        "component_identifier": "Tap-1",
        "installation_date": "today"
    },
    "actor_contact": {
        "email": "installer@acme.com",
        "company": "ACME Corp",
        "phone": "555-1234",
        "category": "Installer"
    }
}

**Common mistakes:**
- Use 'component_identifier', 'component_name', 'equipment_name', or 'ComponentName' (all accepted)
- Both snake_case and PascalCase (COBie standard) are accepted for payload fields
- Field names are case-sensitive: use lowercase 'email', 'company', 'phone', 'category'
- Provide ALL required actor_contact fields at once
- Don't specify output_path unless you want to create a separate copy

**Header requirements:** Workbook must have columns for any payload fields provided
(e.g. SerialNumber, InstallationDate, Status if you include them).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffNo
dry_runNo
payloadYes
key_modeNoname
as_of_dateNo
excel_pathYes
output_pathNo
actor_contactNo
create_backupNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffsNo
errorsNo
dry_runNo
successYes
summaryNo
provenanceNo
updated_atNo
output_pathNo
next_actionsNo
updated_countYes
evidence_itemsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden of explaining side effects, and it does explain in-place editing, output_path behavior, and create_backup. However, it does not describe the dry_run or diff parameters, which control whether changes are actually applied or previewed, so transparency is not complete.

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

Conciseness5/5

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

Although lengthy, the description is well structured with headers, bolded field names, JSON examples, and a common-mistakes list. Every section serves a purpose, and the most critical behavioral warnings are front-loaded.

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?

The description includes complete examples, required actor_contact structure, payload field rules, and header requirements, which is excellent for a tool with nested objects and no schema descriptions. It would be more complete if it addressed dry_run, diff, and key_mode, which are present in the schema but unexplained.

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?

The description covers most important parameters in prose, including excel_path, payload fields, actor_contact, as_of_date, output_path, and create_backup. It omits documentation for dry_run, diff, and key_mode, and since the schema itself has no per-parameter descriptions, those omissions leave gaps in parameter understanding.

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 captures equipment installation data in a COBie workbook during the construction phase, using a specific verb and resource. It distinguishes itself from sibling tools by focusing on installation records rather than lookup, graph, or document management operations.

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 provides extensive usage guidance: it tells the agent to call get_update_workflow or get_actor_contact_schema first, explains the construction-phase workflow, gives minimal and alternative payload examples, and lists common mistakes. It also clarifies what not to ask for (type, floor, space), making the intended use 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