Skip to main content
Glama
Sign In
Archicad MCP Connector

Archicad MCP Connector

by davidharutyunyan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Modify windows, doors, skylights, openings

modify_openings
DestructiveIdempotent

Updates existing windows, doors, skylights, and openings in one undo step by GUID, changing position, size, library part, GDL parameters, flips, and display settings.

Instructions

Changes existing windows, doors, skylights and Opening-tool openings in one undo step. Each item is {guid, ...fields to change} with the same field names as create_windows / create_doors / create_skylights / create_openings (e.g. move a window: position; resize: width/height; swap the library part: libraryPart; GDL: gdlParams; flip: flipped / mirrored). Openings keep their anchorAltitude when anchor/height change — pass bottomElevation to keep the bottom edge instead. The host (wall / roof / owner) cannot be changed — delete and recreate instead. Returns [{guid} | {error}].

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": {
      "openings": "<openings>"
    },
    "name": "modify_openings"
  }
}

Input Schema

NameRequiredDescriptionDefault
openingsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover safety (destructive=true, idempotent=true) but the description adds what they cannot: the whole call is one undo step, per-item return values are '{guid} | {error}' implying partial success, anchorAltitude is preserved when anchor/height change unless bottomElevation is passed, and libraryPart swaps reset GDL params. That is substantive behavioral context beyond the structured fields.

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?

Front-loaded with the verb and scope, then patch shape, field examples, the two subtle semantics (anchor altitude, immutable host), and the return shape. Every sentence carries distinct information with no filler.

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 destructive batch mutation with no output schema, the description supplies the return shape, the failure shape, the transactional scope, and the key constraint (host is immutable). An agent has everything needed to call it correctly and interpret the result.

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 nested schema already documents most fields, but the description adds cross-references the schema lacks: field names mirror the create_* tools, and it maps intents to fields (position to move, width/height to resize, libraryPart to swap, gdlParams for GDL, flipped/mirrored). The anchorAltitude vs bottomElevation interaction is also new meaning not in 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?

States a specific verb and resource ('Changes existing windows, doors, skylights and Opening-tool openings') and frames the operation as a patch rather than a recreate. It is clearly distinguishable from the create_windows / create_doors / create_skylights / create_openings siblings it names.

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?

Gives a strong when-not rule with an alternative: the host wall/roof cannot be changed, so 'delete and recreate instead'. It also explains the patch contract (guid + only the fields to change) and the one-undo-step batching. It does not, however, route the agent between this tool and generic siblings like modify_elements or change_library_part.

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