Model MCP

Overview Schema Source Related Servers Discussions Admin

Move Elements

revit_move

Destructive

Move Revit elements by dx, dy, and dz offsets on model axes. Use dry_run to verify changes and see skipped group, pinned, hosted, or constrained elements.

Instructions

Move elements by dx_mm, dy_mm and dz_mm on model axes. dry_run rolls back and returns the verification block. Group members, pinned, hosted and constrained elements are reported in skipped.inGroup, skipped.pinned, skipped.hosted and skipped.constrained and are not changed; the call is refused if every element is a group member.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "element_ids": "<element_ids>",
      "dx_mm": "<dx_mm>",
      "dy_mm": "<dy_mm>"
    },
    "name": "revit_move"
  }
}

Input Schema

Name	Required	Description
`dx_mm`	Yes
`dy_mm`	Yes
`dz_mm`	No
`dry_run`	No
`document`	No	Title or file name substring of the target open document; needed when several are open.
`element_ids`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.10.0Oct 14, 2026

changedInput schema / properties / document / description

Previous value: -"Case-insensitive substring of the target open document's title or file name. Required to disambiguate when the Revit process has more than one document open; omit only when a single document is open (the active document is used). An unknown or ambiguous reference is rejected before any change."New value: +"Title or file name substring of the target open document; needed when several are open."

removedInput schema / properties / document / title
```
Removed value: -"Document"
```
removedInput schema / properties / dry_run / title
```
Removed value: -"Dry Run"
```
removedInput schema / properties / dx_mm / title
```
Removed value: -"Dx Mm"
```
removedInput schema / properties / dy_mm / title
```
Removed value: -"Dy Mm"
```
removedInput schema / properties / dz_mm / title
```
Removed value: -"Dz Mm"
```
removedInput schema / properties / element_ids / title
```
Removed value: -"Element Ids"
```
removedInput schema / title
```
Removed value: -"revit_moveArguments"
```
removedOutput schema / title
```
Removed value: -"revit_moveDictOutput"
```

Addedv0.7.0Sep 30, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Goes well beyond the destructiveHint/readOnlyHint annotations: it discloses that dry_run rolls back and returns a verification block, enumerates exactly which element classes are skipped (inGroup, pinned, hosted, constrained) and where they are reported, and states the refusal condition when every element is a group member. This is the kind of outcome-level detail an agent needs before committing a destructive transform.

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 dense sentences, front-loaded with the core action before the dry_run and skip-reporting details. No filler, though the skipped.* field enumeration is a long clause that could be tightened.

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?

With an output schema present, return values need not be re-explained, and the description still names the verification block and skip buckets. A destructive mutation tool with annotations and an output schema is covered adequately; only the element_ids semantics remain thin.

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 only 17% (document only), so the description must compensate. It does explain the axis semantics of dx_mm/dy_mm/dz_mm, the dz default behavior implied by omission, and dry_run's effect, but says nothing about element_ids or how document selection interacts with the move.

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?

States a specific verb (Move) and resource (elements) plus the exact displacement axes (dx_mm, dy_mm, dz_mm on model axes). It is distinguishable from siblings like revit_rotate, revit_copy and revit_mirror by naming the transform explicitly, though it never names those siblings by name.

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?

Usage is implied by the parameter semantics and the dry_run/refusal notes, but there is no explicit 'use this instead of revit_rotate/copy/align when...' guidance. The conditions described are edge-case behaviors rather than selection criteria against alternatives.

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

Deploy Server