Revit Model MCP

Overview Schema Source Related Servers Discussions Admin

List Catalog

revit_list_catalog

Read-onlyIdempotent

Discover valid Revit model names before filtering: retrieve categories, family types, levels, views, worksets, phases, or parameters with IDs and counts.

Instructions

Discover valid model names before filtering.

Returns data with section and items containing names and section-specific IDs, categories, types or counts; an empty catalog returns items=[]. section is required: categories, family-types, levels, area-schemes, views, worksets, phases or parameters. The parameters section reports localized names, categories and value types. Start universal queries here, then prefer revit_aggregate_elements for counts and breakdowns; use revit_query_elements only for individual rows. An unknown section, missing document, read failure or timeout raises an error; partial data is not returned.

If more than one Revit instance is running, document is required; otherwise any instance may respond. Non-empty skipped means the answer is incomplete; skippedCount includes entries beyond the first 100.

Input Schema

TableJSON Schema

Name	Required	Description
`section`	Yes
`document`	No	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.
`process_id`	No	Exact positive Revit process ID. Takes precedence over document; if both are supplied they must agree.
`timeout_seconds`	No	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.
`pickup_timeout_seconds`	No	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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.7.0Sep 30, 2026

changedInput schema / properties / document / description

Previous value: -"Case-insensitive substring of the target active document title or file name; default null leaves requests unaddressed, so any instance may respond. Use a unique substring with multiple instances; revit_list_instances instead returns all matching instances, or all instances when omitted."New 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."

addedInput schema / properties / process_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Exact positive Revit process ID. Takes precedence over document; if both are supplied they must agree.",
+  "title": "Process Id"
+}

Changed3 schema fields changedv0.1.1Sep 15, 2026

addedInput schema / properties / document / description

Added value: +"Case-insensitive substring of the target active document title or file name; default null leaves requests unaddressed, so any instance may respond. Use a unique substring with multiple instances; revit_list_instances instead returns all matching instances, or all instances when omitted."

addedInput schema / properties / pickup_timeout_seconds / description

Added 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."

addedInput schema / properties / timeout_seconds / description

Added 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."

First observedSep 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses error behavior (unknown section, missing document, read failure, timeout all raise), that no partial data is returned, and truncation semantics ('skippedCount includes entries beyond the first 100'; non-empty skipped means an incomplete answer). It also covers multi-instance routing. This is meaningful behavior the annotations cannot express.

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?

Purpose and return shape are front-loaded, and every sentence carries information (routing, error modes, truncation). It is dense rather than wasteful, though the run-on packing of routing/error/instance rules into a few long sentences 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?

With an output schema present, the description need not explain return fields, and it still supplies the operationally important extras: multi-instance/document requirement, error conditions, and truncation/incompleteness signals. Nothing critical for calling it correctly 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?

Schema coverage is 80%, and the description still adds value by enumerating the legal section values (categories, family-types, levels, area-schemes, views, worksets, phases, parameters) that the schema leaves as a bare string with no enum, and by explaining that the parameters section reports localized names/categories/value types. It goes modestly beyond the schema without restating the fully documented instance/timeout params.

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+resource ('List Catalog' / 'Discover valid model names') and enumerates exactly what the tool returns (section + items with names, IDs, categories, types, counts). It also differentiates itself from siblings revit_aggregate_elements and revit_query_elements, so an agent can pick it apart from neighbors without opening schemas.

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?

Gives explicit routing: 'Start universal queries here, then prefer revit_aggregate_elements for counts and breakdowns; use revit_query_elements only for individual rows.' That is a concrete when-to-use / when-to-use-something-else rule set, plus the prerequisite that section is required and the multi-instance document requirement.

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

Deploy Server