Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

New project

new_project
Destructive

Creates a new untitled Archicad project, closing the current one. Start from a .tpl template or reset to defaults; choose saveFirst or discardChanges for unsaved work.

Instructions

Creates a new untitled project, CLOSING the current one: from a template (.tpl path — list installed ones with get_project_info {includeTemplates: true}) or with File > New (reset: true = New & Reset, i.e. default settings). You must decide about unsaved changes: saveFirst: true or discardChanges: true. Returns {created, project}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
resetNoWithout template: New & Reset (all settings back to defaults). Default false
templateNoAbsolute path of a .tpl template to start from
saveFirstNoSave the current project in place before continuing (fails for untitled projects: use save_project_as first)
discardChangesNoContinue WITHOUT saving: unsaved changes of the current project are lost. Exactly one of saveFirst / discardChanges must be true

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the safety bar is partly met. The description adds real value beyond that: it discloses that the current project is closed, that unsaved changes must be resolved (saveFirst vs discardChanges), and even the return shape. It does not restate the untitled-project saveFirst failure, which lives only in the schema.

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-loads the destructive action, then packs templates, reset, the unsaved-changes requirement, and the return shape into a compact passage. Parentheticals are dense but each carries information; slightly heavy but no filler sentences.

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?

For a 4-param destructive tool with no output schema, the description covers the side effects, the mutually exclusive save options, and the return value ({created, project}). Nothing essential for a correct call is missing, though edge cases like untitled-project saveFirst failure are left to the schema.

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?

Schema coverage is 100%, so the baseline is 3. The description still adds meaning: it pairs reset with the 'New & Reset' concept, points template at installed .tpl files discoverable via get_project_info, and frames saveFirst/discardChanges as a required either/or decision.

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 ('Creates a new untitled project') and immediately scopes the side effect ('CLOSING the current one'). This clearly separates it from siblings like open_project, close_project, and save_project_as.

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?

Gives concrete conditions: use a .tpl template, or reset:true for New & Reset, and explicitly routes the agent to get_project_info {includeTemplates: true} to list templates. It also states the unsaved-changes decision that must be made. It does not explicitly contrast with open_project/close_project, so a 4 rather than 5.

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