Skip to main content
Glama
roynertr

COBie MCP

by roynertr

update_cobie

Update COBie Excel workbooks by applying structured or natural-language instructions, with dry-run, backup, and output options for safe modifications.

Instructions

Update COBie workbook with structured instructions or natural language text.

**Before first update:** Call get_update_workflow() or get_actor_contact_schema() to get
the required structure and avoid validation errors. 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

**Use Cases:**
- Normal editing: Don't specify output_path (edits original)
- Create a modified copy: Specify output_path
- Safe editing with backup: Set create_backup=True

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

**Input format:** Use EITHER instruction_text OR structured_update_json (not both).

**instruction_text format (natural language):**
- "Update <ComponentName> <FieldName> to <value>"
Examples:
- "Update Tap-1 InstallationDate to 2026-02-16"
- "Update Pump-3A SerialNumber to SN-12345"
- "Update DR:T1A Material to Steel"

**structured_update_json format:**
{
    "instructions": [
        {
            "component_name": "Tap-1",
            "attribute_name": "InstallationDate",
            "new_value": "2026-02-16",
            "target_sheet": "Component",
            "target_key": "Tap-1"
        }
    ]
}

**Common mistakes:**
- Field names are case-sensitive: use lowercase 'email', 'company', 'phone', 'category'
- Provide ALL required actor_contact fields at once (not gradually)
- Don't specify output_path unless you want to create a separate copy

**Safety (commit gate):** Call with dry_run=False only after user has confirmed
the preview. No confirm_token on server; client must enforce confirm_token (e.g.
CONFIRM_APPLY). After commit, call validate_cobie(excel_path) to revalidate.

Example (preview):
    update_cobie(excel_path, structured_update_json={"instructions": [...]},
                 actor_contact=actor, dry_run=True, diff=True)
    # Returns: success, updated_count, errors, diffs, summary, next_actions
Example (commit, after user confirm):
    update_cobie(excel_path, structured_update_json={"instructions": [...]},
                 actor_contact=actor, dry_run=False)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffNo
dry_runNo
key_modeNoname
as_of_dateNo
excel_pathYes
output_pathNo
actor_contactNo
create_backupNo
instruction_textNo
structured_update_jsonNo

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.1/5.0
Behavior5/5

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

With no annotations provided, the description fully carries the burden of explaining side effects. It clearly explains in-place modification, output_path behavior, backup creation, dry-run/commit gating, and post-commit validation, which is exemplary transparency for a mutating tool.

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 long but well-structured with clear sections and bolded headings. It contains repeated or somewhat redundant explanations around file modification behavior and examples, but the organization makes it easy to scan and use.

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 the required workflow, accepted input formats, common mistakes, safety gate, and expected return fields. It covers most needed context for using the tool correctly, though the missing explanation of key_mode and as_of_date leaves minor gaps.

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?

The description explains most parameters, including excel_path, output_path, create_backup, instruction_text, structured_update_json, actor_contact, dry_run, and diff. However, key_mode and as_of_date are not described at all, and diff is only implied through the example return value rather than explicitly defined.

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?

The description clearly states that the tool updates a COBie workbook via structured instructions or natural language, and provides examples. It does not explicitly distinguish itself from sibling tools like preview_update or apply_update_to_graph, but the overall purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete guidance on when to call the tool, including calling get_update_workflow() or get_actor_contact_schema() first, using dry_run for preview, and committing only after user confirmation. It does not explicitly mention alternative update-related sibling tools, but the workflow guidance is strong and actionable.

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