Revit Agent Tools: What an MCP Agent Can Call

What counts as a tool

In MCP terms a tool is a named operation with a typed input schema and a described result. The language model cannot invent capabilities; it can only call what the MCP server publishes, which is why the tool catalogue is the real permission surface of a Revit agent.

Designing that catalogue well matters more than prompt wording. A narrow, well-named set of tools produces more reliable behaviour than a broad set with careful instructions telling the model not to use most of them.

Status and health tools

The cheapest and most important category. A status tool reports whether Revit is running, which document is open, and which view is active. It is the first call to verify when standing up a workstation, and the honest answer to 'is this connection live?'

Revit status

Session state, open document name, active view. Read-only and safe to grant to every agent.

Connector health

Whether the paired workstation is reachable and which capabilities it genuinely exposes.

Read and query tools

These retrieve information without side effects, and they carry most of the practical value of an agent. Because they cannot change the model, they can generally be granted broadly within a project.

Element listing

Enumerate elements by category, level, workset or view, with filters to keep context bounded.

Parameter reads

Fetch instance and type parameter values for specific elements.

Type and family data

Inspect family types, layer build-ups and material assignments.

Model warnings

Retrieve Revit's own warning list for triage and reporting.

Sheets and views

Enumerate sheets, placed views, revisions and titleblock data for documentation checks.

Analysis and preview tools

Preview tools compute a proposed outcome and return it without touching the model. They are the mechanism that makes the preview boundary real rather than a promise in a prompt.

A well-built preview result is reviewable: it names the affected elements, states the proposed value, and where judgement is involved, attaches a confidence value so ambiguous cases can be routed to a human.

Proposed classification

A per-element suggestion with confidence, returned as data rather than applied.

Standards findings

A list of deviations from project conventions, with element references.

Draft extraction

Schedule or quantity drafts derived from current model state, with assumptions noted.

Write tools and the approval gate

Write tools are where governance stops being theoretical. Each one should be granted deliberately, to a specific agent, for a specific job — never as a convenience during testing that is then forgotten.

Destructive operations warrant separate treatment from ordinary parameter updates. Deleting elements, replacing types across a category or bulk-overwriting parameters can be difficult to unwind on a live federated model, and should sit behind their own approval rather than sharing one with benign edits.

Parameter update

Set instance or type parameter values for a reviewed set of elements.

Element creation

Place elements from an approved proposal, within a defined scope.

Type reassignment

Change element types where a preview has been approved.

Deletion

The highest-risk category. Treat as an exception requiring explicit, separate authorisation.

Granting tools well

A practical rule: start every agent with status and read tools only, confirm the output is genuinely useful, then add preview tools, and only add a write tool once there is a reviewer who will actually look at the preview.

Record the grants. Knowing which tools an agent held at the time of a run is part of what makes an audit trail answerable months later, and it is the fastest way to explain an unexpected result.