Revit Model MCP

by sharafutdinovdi

Overview Schema Source Related Servers Discussions Admin

Local

List Revit Jobs

revit_jobs

Read-onlyIdempotent

List recent Revit action jobs or wait for a job result by job ID, with skipped entries indicating an incomplete result.

Instructions

List recent jobs, or wait up to wait_seconds (0 to 50, default 40) for the result of an action jobId. Results stay on the workstation for 24 hours, across server restarts. A non-empty skipped list means the result is incomplete; skippedCount counts all skipped entries.

Input Schema

Name	Required	Description
`job_id`	No
`document`	No	Title or file name substring of the target document; needed when several Revit instances run.
`process_id`	No	Revit process ID; takes precedence over document.
`wait_seconds`	No	Seconds to wait, 0 through 50.
`timeout_seconds`	No	Seconds to wait for a result (default 120).
`pickup_timeout_seconds`	No	Seconds to wait for the add-in to pick up the job (default 300); unused over HTTP.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv0.10.0Oct 14, 2026

removedInput schema / properties / cancel_job_id

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Cancel Job Id"
-}

changedInput schema / properties / document / description

Previous value: -"Case-insensitive substring of the target active document title or file name. Reads require exactly one matching instance; omitted document requires exactly one running instance. Zero or multiple matches fail before publishing. revit_list_instances returns all matching instances, or all running instances when omitted."New value: +"Title or file name substring of the target document; needed when several Revit instances run."

removedInput schema / properties / document / title
```
Removed value: -"Document"
```
removedInput schema / properties / job_id / title
```
Removed value: -"Job Id"
```

changedInput schema / properties / pickup_timeout_seconds / description

Previous value: -"Positive integer seconds to wait for the add-in to pick up a local or SSH job (300 when omitted); ignored over HTTP. A pickup timeout raises an error but the pending job may still execute later."New value: +"Seconds to wait for the add-in to pick up the job (default 300); unused over HTTP."

removedInput schema / properties / pickup_timeout_seconds / title
```
Removed value: -"Pickup Timeout Seconds"
```

changedInput schema / properties / process_id / description

Previous value: -"Exact positive Revit process ID. Takes precedence over document; if both are supplied they must agree."New value: +"Revit process ID; takes precedence over document."

removedInput schema / properties / process_id / title
```
Removed value: -"Process Id"
```

changedInput schema / properties / timeout_seconds / description

Previous value: -"Positive integer seconds to wait for a result after pickup (120 when omitted); HTTP uses this as its response budget. Expiry raises an error, and increasing it does not override the add-in's execution limits."New value: +"Seconds to wait for a result (default 120)."

removedInput schema / properties / timeout_seconds / title
```
Removed value: -"Timeout Seconds"
```

removedInput schema / properties / wait_s

Removed value: -{
-  "default": 40,
-  "description": "Seconds to wait, 0 through 50.",
-  "maximum": 50,
-  "minimum": 0,
-  "title": "Wait S",
-  "type": "integer"
-}

addedInput schema / properties / wait_seconds

Added value: +{
+  "default": 40,
+  "description": "Seconds to wait, 0 through 50.",
+  "maximum": 50,
+  "minimum": 0,
+  "type": "integer"
+}

removedInput schema / title
```
Removed value: -"revit_jobsArguments"
```
removedOutput schema / title
```
Removed value: -"revit_jobsDictOutput"
```

Changed2 schema fields changedv0.9.1Oct 7, 2026

addedInput schema / properties / job_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Job Id"
+}

addedInput schema / properties / wait_s

Added value: +{
+  "default": 40,
+  "description": "Seconds to wait, 0 through 50.",
+  "maximum": 50,
+  "minimum": 0,
+  "title": "Wait S",
+  "type": "integer"
+}

Addedv0.7.0Sep 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description is free to add the behavioral details that matter: the 24-hour result retention 'across server restarts' and the skipped-list/skippedCount semantics for incomplete results. This is substantial, non-obvious context beyond what annotations provide.

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?

Three front-loaded sentences cover the primary purpose, the key parameter, and result interpretation semantics. Every sentence carries information, though the result-retention and skipped-list details could be more tightly integrated.

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 an output schema exists, the description needn't explain return values, and it correctly focuses on behavioral traits (retention, incomplete results). It is nearly complete for a listing/polling tool, though it lacks explicit routing guidance to the batch siblings, which are the most likely alternatives.

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 83%, so most parameters are already documented in the schema. The description nonetheless adds value by restating the wait_seconds range and default, and by explaining the semantic meaning of a non-empty skipped list and skippedCount for interpreting results. It does not, however, explain the distinction between wait_seconds, timeout_seconds, and pickup_timeout_seconds.

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 opens with a specific verb and resource ('List recent jobs'), immediately distinguishing it from the many mutation/view tools in the sibling set. It also maps to its true function of polling for a jobId's result, which no other sibling (aside from revit_batch_status/fetch) does.

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 implies usage ('wait up to wait_seconds for the result of an action jobId'), which gives some context about when to call it. However, it never explicitly names alternatives like revit_batch_status or revit_batch_fetch, nor does it clarify when to poll vs. list, or when not to call it.

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

Deploy Server