Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

Modify meshes

modify_meshes
DestructiveIdempotent

Updates existing Archicad meshes by patching polygon heights, level lines, elevations, skirts, ridges, materials, surfaces, and floor plan attributes while preserving unchanged fields.

Instructions

Changes existing meshes: polygon with point heights (replaces the outline incl. holes), levelLines ([] removes them), level, skirt, skirtLevel, ridges, building material, surfaces, floor plan attributes. Fields as in create_meshes. Only the given fields change; the others keep their values. Each item must be an element of this type (checked first; other items still run). Returns [{guid} | {error}] in input order, one undo step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
meshesYesPatches {guid, ...fields to change}
undoNameNoName of the undo step shown in Archicad

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (destructive=true, idempotent=true), the description discloses critical behavior: partial-update semantics, replacement semantics (polygon replaces the whole outline incl. holes; [] removes levelLines), per-item error isolation ('checked first; other items still run'), the return shape [{guid}|{error}] in input order, and that the call is one undo step. This is rich operational context an agent needs before calling a destructive 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?

Front-loaded with the action, followed by field enumeration, then behavioral rules and return format. Every sentence carries operational weight, though the inline field list is somewhat dense and partly duplicates the schema's enumerated properties.

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?

For a many-parameter mutation tool with no output schema, the description supplies exactly the missing pieces: partial-update behavior, destructive replace/remove semantics, error handling, return format, and undo scope. Nothing essential for correct invocation is left unstated.

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 already 100%, so the baseline is 3, but the description adds genuine value beyond the schema by spelling out the destructive replacement/removal semantics of polygon and levelLines and cross-referencing create_meshes for field definitions. It doesn't restate every parameter's format, which is fine given the schema.

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 opens with a specific verb+resource ('Changes existing meshes') and enumerates the affected fields, making it unmistakable against siblings like create_meshes or modify_elements. An agent can tell this patches mesh elements without opening the schema.

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?

It conveys clear usage context: apply field patches to existing meshes, with partial-update semantics ('Only the given fields change; the others keep their values'). It does not explicitly name the alternative (create_meshes for new meshes) or when-not to use it, so it stops short of full routing guidance.

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