Revit Model MCP

Overview Schema Source Related Servers Discussions Admin

Export View to PNG

revit_export_view

Read-onlyIdempotent

Export a selected Revit view to a PNG file to inspect outlines, zones, and room boundaries when numbers alone are insufficient. Returns local path, dimensions, size, and view metadata without modifying the model.

Instructions

Export a selected view to PNG when numbers do not explain geometry.

Returns data with localPath on the MCP client, image width/height in pixels, sizeBytes and view metadata, without base64. The export does not change the active view or write to the model; use it to inspect outlines, zones and room boundaries. A missing document, unknown or unsupported view, existing destination, missing PNG or download failure raises an error. Uses the default 120-second response and 300-second pickup budgets; timeouts raise errors without partial data.

If more than one Revit instance is running, document is required; otherwise any instance may respond.

Input Schema

TableJSON Schema

Name	Required	Description
`view`	Yes	Required exact, case-sensitive non-template view name from revit_list_views, or its Revit view ID as a decimal string; no default. An exact name takes precedence over interpreting a numeric string as an ID.
`save_to`	No	New PNG file path on the MCP client machine, not the Revit host; an existing destination causes an error. Default null downloads to a local temporary directory and returns localPath.
`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.
`pixel_size`	No	PNG size in pixels along the fitted image dimension, an integer from 1 to 4000. Default 1600 fits the view at that size while preserving its aspect ratio.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 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 / pixel_size / description

Added value: +"PNG size in pixels along the fitted image dimension, an integer from 1 to 4000. Default 1600 fits the view at that size while preserving its aspect ratio."

addedInput schema / properties / save_to / description

Added value: +"New PNG file path on the MCP client machine, not the Revit host; an existing destination causes an error. Default null downloads to a local temporary directory and returns localPath."

addedInput schema / properties / view / description

Added value: +"Required exact, case-sensitive non-template view name from revit_list_views, or its Revit view ID as a decimal string; no default. An exact name takes precedence over interpreting a numeric string as an ID."

First observedSep 15, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavioral detail beyond them: it does not change the active view or write to the model, returns localPath without base64, raises errors for missing documents or existing destinations, uses specific timeout budgets, and explains multi-instance response behavior. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently organized: purpose first, then return details, side-effect guarantees, error conditions, timeout behavior, and multi-instance guidance. Each sentence adds distinct information, and there is no redundant filler.

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?

Given the tool's moderate complexity, the 100% schema coverage, and the presence of an output schema, the description is complete. It covers what the tool returns, what it does not modify, failure modes, timeout behavior, and the multi-instance edge case—everything an agent needs to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces parameter-relevant behavior such as exact view names, existing destination errors, and document disambiguation, but most of this is already present in the input schema. It adds little meaning beyond what the schema already provides.

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 states a specific verb and resource: 'Export a selected view to PNG', and adds the purpose ('when numbers do not explain geometry'). It clearly distinguishes this from sibling query/list tools by framing it as the visual inspection tool for outlines, zones, and room boundaries.

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 context on when to use the tool ('when numbers do not explain geometry', 'use it to inspect outlines, zones and room boundaries') and when multi-instance disambiguation requires the document parameter. It does not explicitly name alternative sibling tools or exclusion conditions, but the intended usage is strongly implied.

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

Deploy Server