Skip to main content
Glama
psxcode

archicad-tapir-mcp

by psxcode

Observe the current Archicad context

archicad_capture_context
Read-only

Records the active Archicad context (stories, sheets, selection, marquee, 2D viewport) to resolve spatial references like 'here' or 'selected'.

Instructions

START HERE after binding when you need to understand words such as here, this, selected, or inside the dashed marquee. Pass target.contextId from archicad_bind; do not bind again by hint. A capture records stories (floors/namespaces) that own sheet_island and outside-sheet drawing_island / loose_fragment regions, plus active selection, marquee, and 2D viewport as independent focus parts. On FloorPlan, default operator intent is the active story (summary.activeStoryHandle): if the operator did not name a floor, stay there. Read stories[] and regionRoles first (sheets and WIP clusters are siblings). Then focusResolution — use preferredRegionHits/preferredResolution for here/this marquee; regionHits remain full multi-story XY truth. For focus questions, report preferred hits first; cards with no matching focusRelationships are not hits. Use maxRegionCards=0 when focus resolution alone is enough. Use current_database when enclosing sheet and nearby cluster/table context matters; selection is a faster exact-workset mode and may omit its surrounding sheet. Keep snapshotId and expand only relevant handles. Detected sheets and title-block fields remain candidates, not ground truth.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoDefault current_database: relates marquee/selection/viewport to enclosing sheets, outside-sheet clusters, and tables. Use selection for a faster exact-workset read of selected BIM/drafting elements (Roof, Window, …); members retain type/bounds/floorIndex even when Tapir type-specific details are unsupported. Selection may omit enclosing sheets.current_database
targetNo
timeoutMsNo
explicitBoundsNoOptional disconnected focus rectangles in Archicad model coordinates. They supplement native selection/marquee/viewport as separate focus parts; they do not crop sheet reconstruction.
maxRegionCardsNoInitial card page size. First page reserves slots for outside-sheet clusters when present. Use 0 for a compact focus-only answer; page regions later by inspecting the returned snapshotId.
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses detailed behavioral traits: what a capture records (stories, selection, marquee, viewport), how focus resolution works (preferredRegionHits), and caveats like 'Detected sheets... remain candidates, not ground truth' and 'selection may omit enclosing sheets.' No contradictions with 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?

The description is well-structured and front-loaded with the critical starting instruction. It is dense but not verbose, with each sentence adding value. A slight reduction in length could improve conciseness, but the current structure effectively guides the agent.

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?

Given no output schema and a complex domain, the description covers the main aspects: what the tool captures, how to interpret results (focus resolution, region roles), and parameter use cases. It could mention error handling or limits, but overall it is sufficiently complete for an agent to use the tool correctly.

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?

The description adds significant meaning beyond the input schema, especially for scope (explaining trade-offs of current_database vs selection) and maxRegionCards (using 0 for focus-only). With 60% schema coverage, the description compensates well, though a few parameters like timeoutMs and explicitBounds have limited additional context.

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 the tool's purpose: 'Observe the current Archicad context' and explicitly explains it is the starting point after binding to resolve ambiguous references like 'here', 'this', 'selected', or marquee. This sets it apart from sibling tools like archicad_read or archicad_discover, which serve different functions.

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?

The description provides explicit usage guidance: 'START HERE after binding' and 'Pass target.contextId from archicad_bind; do not bind again by hint.' It distinguishes when to use selection vs current_database scopes and explains when to set maxRegionCards to 0. Alternatives are implied but the guidance is clear and actionable.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/psxcode/archicad-tapir-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server