Skip to main content
Glama
alesdev88

Archicad-MCP

by alesdev88

Create Road Marking

create_road_marking
Destructive

Places road markings such as lane lines, crossings, bays, and lettering along a path or points, then drapes them onto Archicad Meshes and Slabs for accurate surface fit. Dry-run by default.

Instructions

Place a Road Marking (lane lines, zebra crossings, stop and give way lines, parking rows, disabled, taxi and EV bays, bus and taxi stops, BUS and TAXI lettering) as the 'Road Marking' library part, and drape it onto Meshes and Slabs. The path comes from source_guid (a Morph line, Polyline, Line or Arc) or points [{x, y, z}] in metres. marking is a preset name, for example '5121 Broken divider, in settlements', '5352-1 Disabled bays, shared zone' or '5333-2 Bus stop on the carriageway', or 'Custom'. stripes changes stripes: {"1": {on, offset, width, dash, gap, angle, shape}}; bays sets {layout, width, depth, zone_width, zone_first, bar_width, symbol}; lettering sets {text, length, width, gap, offset, align, shift, repeat}. Offsets, bays and the word lie to the right looking from the first point to the last. drape_on lists Mesh and Slab GUIDs: the cross fall follows the surface, the paint never sinks below it, and nodes are added until the marking is within drape_tolerance (metres) of it along the path; lift raises it. update_guid rewrites a placed marking, keeping its settings unless given; with drape_on and no source it drapes the marking's own path. DRY-RUN BY DEFAULT: reports nodes, the marking's reach, drape deviations, stretches off the surface and warnings. Pass dry_run=false to place or update.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
baysNo
liftNo
portNo
pointsNo
dry_runNo
markingNo
stripesNo
drape_onNo
letteringNo
thicknessNo
flip_sidesNo
source_guidNo
update_guidNo
start_heightNo
whole_dashesNo
paint_surfaceNo
pattern_alignNo
pattern_shiftNo
slope_percentNo
path_toleranceNo
drape_toleranceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=true; the description adds substantial behavioral detail beyond that, including the safe dry-run default, that drape follows surface cross fall with nodes added until within drape_tolerance, that lift raises the marking, and that update_guid keeps prior settings. This is exactly the mutation/safety context an agent needs.

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 and every clause conveys information, but the body is a single dense paragraph chained with semicolons that is heavy to parse. Given the tool's complexity the density is defensible, though some grouping would improve readability.

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?

An output schema exists so return values need not be explained, and the description covers the core workflow: path sourcing, draping, and the dry-run/update lifecycle. The undocumented half of the parameters is the main residual gap for a 21-parameter tool with no annotation detail on them.

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?

With 0% schema description coverage across 21 parameters, the description carries the full burden and explains the semantically hard ones well (source_guid vs points, marking presets, the stripes/bays/lettering sub-fields, drape_on, drape_tolerance, lift, update_guid, dry_run). Roughly ten parameters remain opaque (thickness, flip_sides, pattern_align, pattern_shift, paint_surface, slope_percent, whole_dashes, start_height, port, path_tolerance), so compensation is strong but not exhaustive.

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 names a specific verb (Place) and resource (Road Marking), enumerates the marking types it covers (lane lines, zebra crossings, bays, lettering) and states exactly what it produces (the 'Road Marking' library part draped onto Meshes and Slabs). No sibling tool overlaps this scope, so an agent can distinguish it immediately.

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 clearly explains the operational path: dry-run by default, pass dry_run=false to place, and use update_guid to rewrite a placed marking. It does not contrast itself against alternates like create_elements or create_swept_beam, so there is context but no explicit exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.