archicad-tapir-mcp

by psxcode

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct purpose: discovery, instance listing, capabilities checking, binding, low-level reading, context capturing, inspection, and spatial mapping. Descriptions provide clear guidance on when to use each, minimizing ambiguity.
Naming Consistency3/5
All tools share the 'archicad_' prefix, but the verb/noun pattern is inconsistent: some are verbs (discover, bind, read, inspect), some are nouns (instances, capabilities, spatial_map), and one is verb_noun (capture_context). This mixed style reduces predictably.
Tool Count5/5
With 8 tools, the server is well-scoped for its purpose—interacting with Archicad through discovery, binding, context capture, inspection, and spatial mapping. No tool seems redundant, and the count feels appropriate.
Completeness4/5
The tool surface covers the core workflow: discover instances, bind to one, capture context, inspect elements, and navigate via spatial map. Minor gaps might include lack of update/delete operations, but these align with the read-oriented design.
Average 4.5/5 across 8 of 8 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true or false. The description adds context about it being 'low-level diagnostic' but does not disclose further behavioral traits such as what endpoints are discovered or any side effects.
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?
Two sentences, both essential, with no wasted words. It is front-loaded and concise.
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 low-complexity diagnostic tool with no output schema, the description provides purpose and usage guidance but lacks detail on what the function returns and parameter semantics, leaving gaps for effective agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), and the description does not mention any parameters or add meaning beyond the schema. It fails to compensate for the missing parameter descriptions.
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 it is a 'Low-level diagnostic discovery of Archicad endpoints' and distinguishes itself from the sibling 'archicad_instances' by noting the latter is preferred for routing and human-readable cards.
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?
The description explicitly says to prefer 'archicad_instances' for agent routing and human-readable cards, indicating when not to use this tool. However, it does not fully elaborate on when to use this tool beyond diagnostics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the base safety is known. The description adds rich behavioral detail: paging behavior for specific handle types (story_*, elements_*), return contents for title_block and table handles, and the warning against stale snapshots. This goes well beyond 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of 7 sentences, which is reasonably concise but lacks clear structure (e.g., bullet points or sections). It front-loads the purpose but then mixes details about different handle types without visual separation, making it somewhat dense.
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 the complexity (multiple handle types, pagination, no output schema), the description covers many behavioral aspects: what each handle returns, paging hints, and a warning about snapshot staleness. However, it does not explain pagination semantics (limit/offset) for all handle types, which is a gap.
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 description coverage is low (40%), but the description compensates by explaining how to use handle values (snapshotId, story_*, title_block, table, elements_*) and what each returns. It also advises on detailLevel usage. For limit and offset, it adds nothing beyond the schema, but the overall parameter meaning is significantly enhanced.
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 specifies the verb 'expand' and the resource type 'snapshot, story, region, element-set, or detected-structure handle returned by archicad_capture_context', clearly identifying the tool's function and scope. It distinguishes from siblings by focusing on handle expansion rather than general reading or discovery.
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?
The description provides explicit context: always pass snapshotId, use detailLevel=card first for a region, and recapture instead of using old snapshots. It implies usage after archicad_capture_context but does not explicitly state when not to use or name alternatives, though the sibling list provides that context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is clear. The description adds context about refreshing the background registry, which is a non-destructive side effect, and details the output fields. This goes beyond annotations but is not extensive, earning a 4.
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 two concise sentences that front-load the core purpose and important usage guidance. Every word is meaningful with no redundancy.
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?
Given the simple nature of a listing tool and the absence of an output schema, the description adequately details the output content (project cards with IDs, identity, summary, aliases, focus evidence). It covers the essential behavioral and output information, making it complete for agent use.
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?
The input schema has one parameter (timeoutMs) with no description (0% coverage). The description does not mention this parameter or add any semantic meaning beyond the schema defaults and constraints. Given the low coverage, the description should compensate but fails to do so.
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 title and description clearly state the tool lists routable Archicad projects with specific output details (IDs, identity, summary, aliases, focus evidence). It distinguishes from siblings by specifying 'Use when a target is ambiguous,' implying this tool identifies which instance to use, unlike other tools like archicad_bind or archicad_capabilities.
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 explicitly states when to use this tool ('when a target is ambiguous') and what not to do ('do not ask the user for a port or PID'), providing clear guidance on when it is appropriate versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, idempotentHint, and openWorldHint annotations, the description adds behavioral details: default return count for all_elements/selected_elements, raw mode caution, ambiguity handling, and development-only host/port usage. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a few sentences that front-load the purpose, followed by usage rules and constraints. Every sentence adds value without redundancy.
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 the tool's complexity (5 params, nested requests, no output schema) and good annotations, the description covers key behavioral context: max 20 reads, context reuse, default summary mode, ambiguity handling, and development-only host/port. It could briefly mention return value structure or error handling, but the description is largely complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, but the description adds meaning by explaining when to use target.contextId, that requests can be up to 20, and that host/port are for development only. However, it does not explain each action's parameters or provide detailed semantics for the complex nested requests object.
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 it is for 'low-level diagnostic reads' and explicitly distinguishes it from the 'drawing-understanding workflow.' It contrasts with sibling tools like archicad_capture_context and archicad_inspect, making its purpose unambiguous.
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: prefer archicad_capture_context and archicad_inspect for observation, never call all_elements to validate a semantic snapshot, run up to 20 isolated reads, reuse target.contextId, and use raw mode only when GUIDs are explicitly needed. It also notes that direct host/port is development-only and that ambiguity returns candidate cards instead of guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, confirming safety. Description adds 'It reads no project data' and describes return contents, enhancing transparency without contradiction.
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?
Three sentences front-loaded with usage condition, output list, and safety statement. Every sentence is informative and no redundant text.
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-parameter, no-output-schema tool, the description fully covers purpose, usage, and behavior. It leaves no ambiguity about what the tool does and when to invoke it.
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?
No parameters exist, baseline 4. Description adds value by explaining what the tool returns and when to use it, beyond the schema which is empty.
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 uses a specific verb 'use only when' and clearly states the resource: 'observation hierarchy, recommended call order, handle lifetime, and current correctness rules'. It distinguishes from siblings by specifying when to use it (unsure how tools compose or degraded capabilities).
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?
Explicitly states 'Use only when' with two clear scenarios. It implies when not to use (when not unsure), but does not explicitly name alternative tools, though context from sibling names provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, openWorldHint=false. The description adds behavioral details beyond annotations: painting rules, priority overwrite, resolution derivation, specifics about sheet frames and roof stamps, and that roof stamps use glyph R even when type-specific details are unsupported.
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 dense with information and front-loaded with the main purpose and default scenario. Each sentence adds specific value, but could be slightly more concise with paragraph breaks. No wasted sentences, but length could be trimmed.
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?
With 6 parameters, nested objects, and no output schema, the description covers default behavior, zone options, resolution, BIM enrichment, painting rules, and usage hints. It lacks explicit description of return format (e.g., multi-line string) but 'Doom-style text map' and 'character-grid map' provide enough context for an AI agent.
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 description coverage is given as 67%. The description adds meaning beyond the schema: explains resolution as cell count along longer edge with aspect ratio derivation, default and max; for zone, clarifies what happens when omitted and cautions about passing at most one option; for target, adds 'Opaque sticky context' and usage rules. Compensates for lower coverage.
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 title and description clearly state the tool returns a character-grid text map for spatial orientation, specifying default zone and inputs like regionHandle, explicitBounds, or focusKind. It distinguishes from sibling tools by mentioning it's a secondary navigation aid and referencing snapshotId from archicad_capture_context.
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?
Explicit guidance: default zone is the viewport when zone is omitted; 'Prefer regionHandle when the operator names a specific sheet or cluster'; and 'This is a secondary navigation aid; inspect handles for exact geometry' which advises when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate no read-only/idempotent behavior; description adds that it creates/replaces context and the returned contextId should be carried in later operations, disclosing mutation and usage pattern.
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?
Four sentences, front-loaded with primary purpose, followed by clear preference hierarchy. No redundancy.
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?
Covers parameter use and ambiguous cases, but lacks error handling or failure scenarios. Adequate given no output 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 description coverage is low (20%), but the description explains when to use each parameter (hint, instanceId, useRecentForeground) and adds constraints for confirmAlias, compensating for gaps.
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?
Description clearly states it 'creates or replaces a sticky target context' and distinguishes from siblings by listing preferred methods (project hint, instanceId, useRecentForeground).
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?
Explicitly provides decision criteria: prefer project hint for saved projects, instanceId from candidate cards, useRecentForeground only after user foregrounded. Also advises to show candidates if ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![archicad-tapir-mcp MCP server](https://glama.ai/mcp/servers/psxcode/archicad-tapir-mcp/badges/card.svg)](https://glama.ai/mcp/servers/psxcode/archicad-tapir-mcp)

Score Badge

Copy to your README.md:

[![archicad-tapir-mcp MCP server](https://glama.ai/mcp/servers/psxcode/archicad-tapir-mcp/badges/score.svg)](https://glama.ai/mcp/servers/psxcode/archicad-tapir-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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