R3

Read the ground height of a terrain

r3_terrain_height

Read-onlyIdempotent

How high the ground of a heightfield terrain is at the world (x, z) positions you ask, exactly as physics and the drawn terrain have it, plus the terrain's lowest and highest point, centre, size and footprint. Use it to place something ON a terrain: an object stands on the ground at (x, z) when its lowest point is at the returned y (a vehicle: its wheels' bottom); the returned ground normal says how steep it is there. One call takes up to 100 points; with none it describes the terrain only.

terrain is the terrain's Mesh, GeometryHeightfield or ColliderHeightfield (entityRef or id); leave it out when the project has one terrain.

It reads the user's open R3 editor when it has the project (the terrain as on screen, a heightmap image included), else the saved project. A terrain shaped by a heightmap IMAGE needs the project open in R3 (r3_editor_open), because only a browser decodes the image. Read-only: nothing is changed.

Input Schema

Name	Required	Description
`points`	No	World positions to sample, e.g. [{"x": 0, "z": 12.5}]. Up to 100.
`terrain`	No	The terrain: its Mesh, GeometryHeightfield or ColliderHeightfield, by entityRef or id. Optional when the project has one terrain.
`projectId`	Yes	The project, from r3_project_list or r3_project_create.

Output Schema

Name	Required	Description
`answer`	Yes	This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.
`editor`	Yes
`points`	Yes
`source`	Yes
`terrain`	Yes
`projectId`	Yes
`projectName`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

changedOutput schema / properties / editor / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "additionalProperties": false,
-        "properties": {
-          "lastActiveAgoMs": {
-            "type": "number"
-          },
-          "lastActiveAt": {
-            "type": "string"
-          },
-          "openProjects": {
-            "anyOf": [
-              {
-                "items": {
-                  "additionalProperties": false,
-                  "properties": {
-                    "id": {
-                      "type": "string"
-                    },
-                    "name": {
-                      "type": [
-                        "string",
-                        "null"
-                      ]
-                    }
-                  },
-                  "required": [
-                    "id",
-                    "name"
-                  ],
-                  "type": "object"
-                },
-                "type": "array"
-              },
-              {
-                "type": "null"
-              }
-            ]
-          },
-          "openedAt": {
-            "type": [
-              "string",
-              "null"
-            ]
-          }
-        },
-        "required": [
-          "openedAt",
-          "lastActiveAt",
-          "lastActiveAgoMs",
-          "openProjects"
-        ],
-        "type": "object"
-      },
-      {
-        "type": "null"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "anyOf": [
+      {
+        "additionalProperties": false,
+        "properties": {
+          "frames": {
+            "anyOf": [
+              {
+                "additionalProperties": false,
+                "properties": {
+                  "advancing": {
+                    "type": "boolean"
+                  },
+                  "frameSeen": {
+                    "type": "boolean"
+                  },
+                  "sceneShown": {
+                    "type": "boolean"
+                  },
+                  "visible": {
+                    "type": "boolean"
+                  }
+                },
+                "required": [
+                  "advancing",
+                  "visible",
+                  "sceneShown",
+                  "frameSeen"
+                ],
+                "type": "object"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "lastActiveAgoMs": {
+            "type": "number"
+          },
+          "lastActiveAt": {
+            "type": "string"
+          },
+          "openProjects": {
+            "anyOf": [
+              {
+                "items": {
+                  "additionalProperties": false,
+                  "properties": {
+                    "id": {
+                      "type": "string"
+                    },
+                    "name": {
+                      "type": [
+                        "string",
+                        "null"
+                      ]
+                    }
+                  },
+                  "required": [
+                    "id",
+                    "name"
+                  ],
+                  "type": "object"
+                },
+                "type": "array"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "openedAt": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "openedAt",
+          "lastActiveAt",
+          "lastActiveAgoMs",
+          "openProjects"
+        ],
+        "type": "object"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  {
+    "type": "null"
+  }
+]

AddedOct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly/idempotent/openWorld/destructive=false) by disclosing the data-source resolution rule (reads the user's open editor when it holds the project, otherwise the saved project), the heightmap-image constraint that only a browser can decode, and the 100-point cap per call. It also confirms 'nothing is changed', consistent with the safety annotations.

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?

Front-loaded with the core purpose and return shape, then constraints and parameter notes in a logical order. Dense but every sentence carries information; no filler or tautology. Slightly heavy prose style keeps it from a clean 5.

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?

An output schema exists, so return values need not be re-explained, yet the description still covers purpose, usage, prerequisites, source-of-truth behavior and parameter edge cases. Nothing an agent needs to invoke 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 already 100% (baseline 3), but the description adds genuine meaning: the accepted terrain reference kinds (Mesh, GeometryHeightfield, ColliderHeightfield; entityRef or id), the fact that omitting terrain is allowed when the project has one terrain, and the behavior of omitting points (describe the terrain only) with the 100-point limit.

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?

Starts with a specific verb+resource: reading the ground height of a heightfield terrain at world (x, z) points, and names the full return set (point heights, lowest/highest point, centre, size, footprint). No sibling tool covers terrain-theight sampling, so it is trivially distinguishable from the surrounding list.

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?

Gives concrete when-to-use guidance ('use it to place something ON a terrain... an object stands on the ground when its lowest point is at the returned y') plus a hard prerequisite: terrains shaped by a heightmap image require the project open in the R3 editor (r3_editor_open). It does not state an explicit when-not-to-use case, but the selection context is clear.

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

All R3 tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?