revit-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REVIT_BRIDGE_HOST | No | Host where the add-in listens | 127.0.0.1 |
| REVIT_BRIDGE_PORT | No | TCP port of the add-in | 18080 |
| REVIT_BRIDGE_TOKEN | No | Pre-shared token, sent with every request when the add-in has one configured | (unset) |
| REVIT_BRIDGE_TIMEOUT | No | Seconds to wait for a command to finish | 60 |
| REVIT_BRIDGE_CAPABILITIES_DIR | No | Directory of capability YAML files; new solidify_tool packs are written here | packaged packs |
| REVIT_BRIDGE_ALLOW_UNCONFIRMED | No | 1 lifts the spec_confirmed gate (host-internal flows only) | (unset) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| execute_codeA | Send C# code to Revit for execution over the local TCP socket. Refused unless spec_confirmed=true (the designer confirmed the task spec). Returns execution result or error message. |
| solidify_toolB | Save a successful code execution as a reusable named tool. parameters: JSON array of {name, type, description, source?, default?, choices_from?} tags: comma-separated tags |
| list_toolsA | List all solidified tools available for execution. |
| get_tool_choicesA | Query Revit for dynamic parameter choices of a solidified tool. Call this BEFORE run_tool to discover available levels, family types, etc. Returns {param_name: [{label, value}, ...]} for parameters that need selection. |
| run_toolA | Execute a solidified tool by name with given parameters. IMPORTANT: Call get_tool_choices first for parameters with choices_from / source: query:*. Refused unless spec_confirmed=true (the designer confirmed the task spec). params: JSON object of parameter values, e.g. {"level_name": "L1", "height": 3000} |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| api_stats | Solidified tool statistics. |
| connection_status | Check whether the Revit add-in is reachable. |
TDQS
Scored across 5 tools
Most tools have clearly distinct roles: execute_code runs raw C#, run_tool runs saved tools, solidify_tool creates them, and list_tools/get_tool_choices support discovery. However, execute_code and run_tool both perform execution, which could cause an agent to misselect when only one is appropriate.
All tool names follow a consistent verb_noun snake_case pattern: execute_code, solidify_tool, list_tools, get_tool_choices, run_tool. The naming is predictable and makes the surface easy to navigate.
Five tools is well-scoped for a Revit bridge: execute raw code, solidify it, list solidified tools, query parameter choices, and run a solidified tool. Each tool earns its place with no unnecessary redundancy.
The set covers creating, listing, querying, and running solidified tools, but lacks update and delete operations for those tools. There is also no way to view a single tool's details, leaving the lifecycle partially incomplete.