Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

by davidharutyunyan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Create fill types

create_fills

Create solid, vector, gradient, and image fills for Archicad. Define hatch patterns, copy existing fills, and apply them to building materials, hatches, and cover fills.

Instructions

Creates fill types: Solid (percentage/screen fill with percent: 25, or an explicit bitmapPattern, e.g. '55AA55AA55AA55AA' = 50%), Empty, Vector (hatch lines in mm on paper, e.g. {name: 'Diagonal 2mm', lines: [{angle: 45, spacing: 2}]}; with scaleWithPlan: true the values are meters in the model, e.g. a 0.3 m tile grid [{angle: 0, spacing: 0.3}, {angle: 90, spacing: 0.3}]), LinearGradient / RadialGradient, Image (texture). Symbol fills and any other fill can be copied with basedOn / duplicate_attributes. Use fills in building materials (cutFill), hatches, zone/slab cover fills. Runs in one undo step. Returns {results: [{index, name, guid, created: true} | {..., existed: true} | {error}]} in input order; one failing item does not stop the others. Names are localized (Russian Archicad): look existing attributes up with get_attributes first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fillsYes
ifExistsNoName collision handling for all items: 'error' (default), 'skip' (reuse the existing attribute), 'update' (apply the fields to it)

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 only declare readOnlyHint=false / destructiveHint=false / idempotentHint=false; the description adds real behavioral context: single undo step, per-item result shape in input order, one failing item does not abort the others, and Russian-localized naming caveats. Nothing contradicts the annotations.

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 core purpose and packed with dense parenthetical examples; every sentence carries information, but the single sprawling paragraph mixes type semantics, copying, return values, and localization, making it harder to scan than a structured list would be.

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?

No output schema exists, yet the description spells out the return shape `{results: [{index, name, guid, created} | {existed} | {error}]}` and partial-failure behavior. Combined with the indexing/collision guidance, it is complete for a complex destructive-adjacent attribute creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Goes well beyond the schema with worked examples: percent: 25, bitmapPattern '55AA55AA55AA55AA' = 50%, vector hatch {name:'Diagonal 2mm', lines:[{angle:45, spacing:2}]}, and the scaleWithPlan meter-vs-mm reinterpretation ({angle:0, spacing:0.3} tile grid). These examples clarify units and semantics the schema alone leaves ambiguous.

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?

Opens with a specific verb+resource ('Creates fill types') and immediately enumerates the concrete kinds supported (Solid, Empty, Vector, LinearGradient, RadialGradient, Image). This lets an agent distinguish it from siblings like create_hatches, create_surfaces, and create_line_types without opening any 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?

States where fills are consumed ('building materials (cutFill), hatches, zone/slab cover fills') and routes the agent to get_attributes before looking up localized names, plus duplicate_attributes/basedOn for copying Symbol fills. Clear usage context, though it doesn't explicitly state when NOT to use this tool versus create_hatches/create_surfaces.

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