Revit Model MCP

Overview Schema Source Related Servers Discussions Admin

List Warnings

revit_list_warnings

Read-onlyIdempotent

Review Revit model warnings grouped by description, with counts and affected elements. Filter by warning text to drill into one issue.

Instructions

Group model warnings by description text.

Returns data with totalWarnings and groups containing text, severity, count, affectedElementCount and optional element rows. Start without filters, then repeat with a returned warning_text and include_elements=true to inspect one group. No model warnings return groups=[]; an unmatched warning_text raises an error. A 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.

Input Schema

TableJSON Schema

Name	Required	Description
`document`	No	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.
`warning_text`	No	Exact warning description from revit_list_warnings, matched case-insensitively. Default null includes all warning groups; an unmatched supplied text raises an error.
`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.
`include_elements`	No	Whether warning groups include affected elements with ID, category and name. Default false returns counts without element rows; combine true with warning_text to inspect one group.
`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.

Changed5 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 / include_elements / description

Added value: +"Whether warning groups include affected elements with ID, category and name. Default false returns counts without element rows; combine true with warning_text to inspect one group."

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

addedInput schema / properties / warning_text / description

Added value: +"Exact warning description from revit_list_warnings, matched case-insensitively. Default null includes all warning groups; an unmatched supplied text raises an error."

First observedSep 15, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavioral context: empty results return groups=[], unmatched warning_text raises an error, failures/timeouts raise errors without partial data, and multi-instance behavior requires document. This goes well beyond what annotations alone 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?

The description is organized into dense, purposeful paragraphs with the primary action front-loaded. Every sentence adds operational value, though the multi-instance note and error behavior are repeated in the schema parameter descriptions, adding slight 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?

With an output schema present, the description need not explain return values in detail. It covers the core return shape, error conditions, no-partial-data guarantee, multi-instance document routing, and the recommended filter/inspection workflow. This is complete for an agent to invoke and iterate 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?

Schema coverage is 100%, so the schema thoroughly documents all parameters. The description adds workflow guidance that ties parameters together ('Start without filters, then repeat with a returned warning_text and include_elements=true'), which is meaningful beyond the schema's isolated parameter definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Group model warnings by description text.' It clearly conveys the action and scope, but it does not explicitly differentiate itself from the sibling tool revit_view_warnings, so an agent might need extra inference to choose between them.

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 gives clear usage context: 'Start without filters, then repeat with a returned warning_text and include_elements=true to inspect one group' and explains the multi-instance document requirement. It does not explicitly state when to use this tool versus alternatives like revit_view_warnings, but the workflow guidance is strong.

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

Deploy Server