Skip to main content
Glama
Sign In
Archicad MCP Connector

Archicad MCP Connector

by davidharutyunyan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Create interior elevations

create_interior_elevations

Creates interior elevation markers from a room polyline, making each wall segment a separate elevation view for Archicad documentation.

Instructions

Creates interior elevation markers (one undo step): 'points' is a polyline inside a room along its walls; every segment becomes one interior elevation view (closed: true for all walls). depth = view depth per segment (m). If a view looks the wrong way, recreate it with the points in reverse order. Returns [{guid, name, segments: [{index, name, database}]}] — open a segment with open_view {element, segmentIndex}.

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": {
      "interiorElevations": "<interiorElevations>"
    },
    "name": "create_interior_elevations"
  }
}

Input Schema

NameRequiredDescriptionDefault
undoNameNo
interiorElevationsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds real context beyond them: the operation is 'one undo step', it is not idempotent in practice (wrong-facing views must be recreated), and it returns a guid/segment structure. That is meaningful, non-obvious behavioral detail.

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?

Purpose is front-loaded, then mechanism, then parameters, then return shape and next step. Dense but each clause carries information; a single compact paragraph with no filler.

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?

With no output schema, the description usefully supplies the return shape ([{guid, name, segments:[{index, name, database}]}]) and the follow-up call (open_view with element, segmentIndex). Combined with annotations covering the safety profile, an agent has enough to call and chain it correctly; only undoName and the many optional marker fields go unmentioned.

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?

Top-level schema coverage is 0% and undoName is undocumented anywhere, so the description carries some burden. It does add meaning for the key nested fields ('points' as a wall polyline, depth as per-segment view depth in m, closed for all walls), though the nested schema descriptions already state most of this.

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?

States a specific verb+resource ('Creates interior elevation markers') and explains the mechanism (polyline along room walls, one view per segment). It does not explicitly distinguish itself from siblings like create_elevations, create_sections, or create_details, so sibling differentiation is left to inference.

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

Usage Guidelines3/5

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

Gives operational usage hints: points should run along the inside of walls, closed:true covers all walls, and a wrong-facing view is fixed by reversing the point order. It also routes to open_view for the follow-up step. However, it never states when to use this instead of create_elevations/create_sections or any precondition/exclusion.

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