Skip to main content
Glama
Sign In

Polyfork low-poly 3D assets

by dev.polyfork
OverviewDiscussionsAdmin

get_terrain

AT WHAT HEIGHT DO I PLACE THIS, and where can I build. Many kits have a procedural TERRAIN program for their own ground (call with no id for which: the rest stand on floor tiles or flat turf, where y 0 is right). Ask with the KIT id to get the ground its composed place stands on, in place.group's coordinates, which is what buildKit builds and what place.groundAt(x, z) reads (setting: true for buildKit's wider setting ground); a terrain ASSET id answers for that program alone at its default knobs, a different patch of ground. Pass at with the x/z you want to place at and you get the ground height there; set position.y to it. flat_areas are the level building sites: square footprints whose ground barely varies, largest first, none overlapping, with the height to place at. Use it before laying out a town, a farm or a depot, instead of guessing a y and hoping. Pass profile to get the ground along a proposed road or wall: heights, the grade between points, and whether each point is under water, so you know where a bridge is needed. Every answer says its frame, so it can be used directly. Terrain from two different kits joins edge to edge on a shared 64m grid, so several kits can share one landscape.

Input Schema

NameRequiredDescriptionDefault
atNox,z;x,z;… — AT WHAT HEIGHT DO I PLACE THIS. Returns the ground height and slope under each point; set the object's position.y to the y you get back and it rests on the terrain. Use this for anything that is not going on one of the level sites. Up to 64 points.
idNoa KIT id (the ground its composed place stands on, as buildKit builds it) or a terrain asset id (that program alone). Omit to list every kit that has ground.
nearNox,z,radius: keep the scatter points inside that circle, for dressing one clearing rather than the whole block
spanNoblock size in 64m chunks, 1 to 4. Bigger blocks have more room and more sites.
flatsNohow many level sites to return (default 12, max 40)
erosionNo0 to 1. Weathers the landforms: valleys smooth out, crests stay sharp. Changes where the level sites are, so ask with the same value you intend to build with.
flattenNo0 to 1. Clears a level area in the MIDDLE of the block for a settlement, leaving the landscape around it. Raise it when the natural sites are too small for what you are placing.
profileNox0,z0,x1,z1[,steps] — the ground along a straight line, for a road, a wall or a bridge
scatterNon placement points the terrain picks itself, already on the ground and already filtered to slopes gentle enough to stand on, each with a random yaw. For rocks, trees and dressing.
settingNowith a kit id: the ground of buildKit({ setting: true }), twice the composed span, instead of the composed place's

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / id / description
      Previous value: -"terrain asset id. Omit to list every kit that has one."New value: +"a KIT id (the ground its composed place stands on, as buildKit builds it) or a terrain asset id (that program alone). Omit to list every kit that has ground."
    • addedInput schema / properties / near
      Added value: +{
+  "description": "x,z,radius: keep the scatter points inside that circle, for dressing one clearing rather than the whole block",
+  "type": "string"
+}
    • addedInput schema / properties / setting
      Added value: +{
+  "description": "with a kit id: the ground of buildKit({ setting: true }), twice the composed span, instead of the composed place's",
+  "type": "boolean"
+}
    • removedInput schema / required
      Removed value: -[
-  "id"
-]
  2. First observed

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose genuinely non-obvious behavior: answers carry a `frame`, different kits join on a shared 64m grid, terrain asset ids answer at default knobs while kit ids answer in place.group's coordinates, and `setting` widens the ground. It stops short of stating that the call is side-effect-free and read-only, or whether results are deterministic/cacheable across repeated calls — a meaningful omission for a tool with ten knobs, keeping it at a 3 rather than higher.

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

Conciseness2/5

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

One dense run-on paragraph with several clauses that restate the schema verbatim (the opening "AT WHAT HEIGHT DO I PLACE THIS" is copied from the `at` parameter description), so parts of it are duplicated rather than additive. The key guidance — read `frame`, set position.y — is buried mid-paragraph rather than front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With ten parameters, no annotations and no output schema, the description conveys enough to invoke it correctly in each mode and explains the `frame` convention. But it never sketches the shape of a response (what the flat_areas objects or profile result contain), and gives no contract for why values change between default and override knobs, leaving an agent to discover return structure by calling.

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 coverage is 100%, so the schema itself already documents all ten parameters at length. The description mainly reinforces semantics the schema already gives — `id` as kit-vs-asset, `at` for placement height, `profile` for roads and walls — with little added detail such as default values for `erosion`/`flatten` or what `scatter` points actually look like beyond the schema text.

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 does real work: it names the resource (terrain/ground height) and the specific questions it answers (placement height, level build sites, road grade profiles), and it ties them to concrete consumers (buildKit, place.groundAt(x, z)). The kit-id vs terrain-asset-id distinction lets an agent tell which of two similar-looking queries it wants without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use with the alternative it replaces: "Use it before laying out a town, a farm or a depot, instead of guessing a y and hoping." It also routes within the tool itself — omit id to list kits, pass `at` for point heights off level sites, pass `profile` when a bridge is needed — so each mode has a stated trigger.

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

All Polyfork low-poly 3D assets toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources