Archicad-MCP

by alesdev88

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Find collisions

find_collisions

Read-only

Instructions

Find clashes: which elements of one group collide with which elements of another (Tapir). The first group is guids plus every element of element_types; the second is against_guids plus against_types, and without it the first group is checked against itself. Element types are Archicad's names (Wall, Beam, Column, Slab, Object, Morph, ...); for property criteria call find_elements first and pass its GUIDs. volume_tolerance (m3, default 0.001) is the overlap volume below which a clash is ignored; surface_tolerance (m2) also reports touching faces over that area. Returns each pair with both elements' type and ID, the first one's story, and kind (body, clearance for MEP clearance zones, or both), counts by type pair, and 'elements', every GUID in a pair, to pass to show_elements. Archicad does not count elements its own junctions clean up (crossing walls); the volume check sees only closed bodies, so an open surface (a Morph surface) clashes only with surface_tolerance set; building materials set not to take part in collision detection are left out. No pairs is not proof that nothing overlaps. A whole-model check can take a while. Reads only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_collisions"
  }
}

Input Schema

Name	Required	Description	Default
`port`	No
`guids`	No
`against_guids`	No
`against_types`	No
`element_types`	No
`volume_tolerance`	No
`surface_tolerance`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.10.0Oct 22, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the closing 'Reads only' is consistent rather than contradictory. Beyond that, the description discloses genuinely non-obvious behavior: Archicad ignores clashes its own junctions clean up, the volume test only sees closed bodies, collision-excluded building materials are skipped, an empty result is not proof of no overlap, and whole-model checks are slow. That is exactly the kind of caveat an agent cannot get from 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense and nearly every sentence adds operational value, but it is delivered as one long unbroken paragraph mixing calling convention, tolerances, return shape, and Archicad caveats. The return-format sentence is partly redundant with the existing output schema, and breaking the text into grouped statements would make it far easier to parse.

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 zero-required-parameter geometric query tool, the description covers selection, operand grouping, tolerance semantics, performance expectations, and known blind spots. With an output schema already present, nothing an agent needs in order to invoke this correctly and interpret an empty result is missing.

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?

Schema description coverage is 0%, so the description carries the full burden and mostly succeeds: it gives the meaning of guids/against_guids/element_types/against_types, the valid Archicad type names with examples, and the units and defaults for volume_tolerance (m3, 0.001) and surface_tolerance (m2, touching faces). Only the connection parameter 'port' is left unexplained, which is a minor gap against an otherwise thorough semantic account.

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 ('Find clashes: which elements of one group collide with which elements of another') and immediately defines the two operand groups, so the agent knows exactly what computation is performed. It also differentiates itself from the sibling find_elements by assigning it a distinct role (identifier resolution, not geometric search).

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

Usage Guidelines5/5

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

Spells out the group composition rules (guids + element_types vs against_guids + against_types), the self-check fallback when the second group is empty, the prerequisite routing ('for property criteria call find_elements first and pass its GUIDs'), and the specific case where surface_tolerance must be set (open Morph surfaces). This is explicit when-to-use and how-to-configure guidance, not inference.

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

Deploy Server