Archicad-MCP

by alesdev88

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Import issues from BCF

import_issues_bcf

Destructive

Import BCF issues from a file into Archicad, aligning them to the survey point (requires Tapir add-on).

Instructions

Import issues into the project from a BCF file, aligned to the survey point (requires the Tapir add-on).

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": {
      "bcf_path": "<bcf_path>"
    },
    "name": "import_issues_bcf"
  }
}

Input Schema

Name	Required	Description	Default
`port`	No
`bcf_path`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Sep 2, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already convey readOnlyHint=false and destructiveHint=true, and the description's 'Import issues' is consistent with a write/import operation. It adds some behavioral context with 'aligned to the survey point' and the Tapir add-on requirement, but does not explain merge, overwrite, or duplicate-handling behavior.

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?

The description is a single efficient sentence that front-loads the core purpose, then adds a prerequisite and an important alignment detail. Every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with destructive annotations and an output schema, the description covers the main purpose, the required source file, and a prerequisite. Still, the port parameter and the operational impact (e.g., whether existing issues are modified or duplicated) are not addressed, leaving some gaps.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It indirectly clarifies bcf_path by mentioning 'a BCF file', but the port parameter is left completely unexplained despite being part of the input 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?

The description clearly states a specific action ('Import issues into the project from a BCF file') and the resource being acted on. It also adds the alignment-to-survey-point detail, which helps distinguish this import tool from related tools like create_issue or export_issues_bcf.

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?

The description implies usage — importing issues from a BCF file — and mentions the Tapir add-on prerequisite. However, it does not explicitly contrast with alternatives such as create_issue for individual issue creation or export_issues_bcf for the inverse operation.

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

Deploy Server