Revit Model MCP

Overview Schema Source Related Servers Discussions Admin

Execute C# Code

revit_execute_code

Destructive

Compile and run C# against the live Revit API on Revit's thread to automate model queries or changes, with one undo entry and optional dry-run/confirmation.

Instructions

Compile and run C# against the live Revit API on the Revit thread. Accepts a method body or a public static Script class with Execute(ScriptContext ctx). Auto mode owns one transaction and undo entry; transaction="none" is refused by default. Needs confirm_token from a first call, which runs nothing; dry_run needs none. A long action can return status=running and jobId when the wait budget expires; it may already have changed the model, and revit_jobs returns its result. Resubmitting repeats the action.

Input Schema

Name	Required	Description	Default
`code`	Yes
`dry_run`	No
`document`	No	Title or file name substring of the target open document; needed when several are open.
`transaction`	No		auto
`confirm_token`	No
`timeout_seconds`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.10.0Oct 14, 2026

removedInput schema / properties / code / title
```
Removed value: -"Code"
```
removedInput schema / properties / confirm_token / title
```
Removed value: -"Confirm Token"
```

changedInput schema / properties / document / description

Previous value: -"Case-insensitive substring of the target open document's title or file name. Required to disambiguate when the Revit process has more than one document open; omit only when a single document is open (the active document is used). An unknown or ambiguous reference is rejected before any change."New value: +"Title or file name substring of the target open document; needed when several are open."

removedInput schema / properties / document / title
```
Removed value: -"Document"
```
removedInput schema / properties / dry_run / title
```
Removed value: -"Dry Run"
```

removedInput schema / properties / response_timeout_s

Removed value: -{
-  "default": 600,
-  "maximum": 3600,
-  "minimum": 30,
-  "title": "Response Timeout S",
-  "type": "integer"
-}

addedInput schema / properties / timeout_seconds

Added value: +{
+  "default": 600,
+  "maximum": 3600,
+  "minimum": 30,
+  "type": "integer"
+}

removedInput schema / properties / transaction / title
```
Removed value: -"Transaction"
```

removedInput schema / title

Removed value: -"revit_execute_codeArguments"

removedOutput schema / title

Removed value: -"revit_execute_codeDictOutput"

Addedv0.9.1Oct 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description materially extends that: it explains transaction ownership and the undo entry, that transaction="none" is refused by default, that a long action may return status=running with a jobId *after possibly mutating the model*, and that resubmitting repeats the action. These are exactly the side-effect, recoverability, and non-idempotency details an agent needs and cannot get from the annotations alone.

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 purpose clause is front-loaded and each following clause carries distinct, non-redundant behavioral information with no filler. It is dense to the point of being a run-on of semicolon-joined fragments, which slightly hurts scannability.

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 high-risk code-execution tool with an output schema (so return values need no explanation), the description covers the full call lifecycle: code format, transaction semantics, the confirmation handshake, dry-run safety, and the async job handoff to revit_jobs. Nothing an agent needs to invoke it safely is missing.

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?

With only 17% schema description coverage across 6 params, the description carries the load and mostly delivers: it specifies the two accepted forms of `code` (method body vs. Script class with Execute(ScriptContext ctx)), the meaning of `transaction` (auto vs. none and the default refusal), when `confirm_token` is required, and that `dry_run` needs no token. It only gestures at `timeout_seconds` via 'wait budget' and relies on the schema for `document`, so a small gap remains.

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 ('Compile and run C# against the live Revit API') and pins down where it executes ('on the Revit thread'). The 'execute arbitrary code' framing clearly separates it from the numerous narrow siblings like revit_run_actions, revit_update_parameters, and revit_batch_start without needing to open any schema.

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 is rich on *how* to invoke (two-step confirm_token flow, dry_run needing no token, resubmission behavior) and routes results to revit_jobs, but it never states *when* to prefer this escape hatch over the many purpose-built sibling tools. It implies usage through mechanism rather than giving explicit when-to-use/when-not guidance or an alternative, so it lands at the implied-usage level.

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

Deploy Server