Skip to main content
Glama

Polyfork low-poly 3D assets

get_kit

Every published part of one kit, as shortlisting rows (compact: false gives each row the detail get_asset gives: preview_glb, downloads, rig), so you can compose a whole scene from one call. Works on a kit that is still FILLING UP: you get the parts that exist today. NO kit is sold as a bundle, at any status, so recommend its parts rather than the kit: every part is free, with no account for its /cdn files. A kit may also carry look and terrain. look is the shader it is presented under — the Coral Reef is composed, photographed and filmed through 2.5 m of water — and it ships with the download as looks.mjs, three lines to apply, nothing baked into the geometry. terrain is the kit's own ground program with the knob values it was composed at. Build the scene without them and it is the same parts on a flat floor in clear air, which is not what any picture of the kit shows. And if the connection OWNS the kit, layout is the composition itself: every placement of every part, with the position, the rotation and the knob values that placement was built with. That is the arrangement the kit was photographed and filmed in, so you can rebuild it exactly and then change it, rather than inventing a layout from scratch. composition reports how many placements there are whether you own it or not. To BUILD that place, do not read the rows: build_the_whole_place is three lines of code (buildKit from /cdn/kit.mjs) that assemble every placement, merged for speed, with collision boxes and the kit's own ground. Start a game level or a scene from that and change it.

Input Schema

NameRequiredDescriptionDefault
idYeskit id, from list_kits or an asset's `kit` field
compactNoshortlisting rows (the default) instead of full detail. false gives every row what get_asset gives, a large result for a 60-part kit; building the place needs neither (`build_the_whole_place`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / compact / description
      Previous value: -"shortlisting rows instead of full detail. A 45-part kit at full detail is a large result; use this when you are surveying rather than building."New value: +"shortlisting rows (the default) instead of full detail. false gives every row what get_asset gives, a large result for a 60-part kit; building the place needs neither (`build_the_whole_place`)."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does most of it: it discloses that kits fill incrementally, that no kit is sold as a bundle, that parts are free with no account for /cdn files, and that `layout` only appears when the connection owns the kit. It also warns compact:false is a large result for a 60-part kit. It stops short of error behavior or pagination/rate limits.

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

Conciseness3/5

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

The first sentence is well front-loaded, but the body drifts into scene-setting prose about photographing the Coral Reef through 2.5 m of water and repeats 'photographed and filmed'. Worthwhile content (build routing, ownership-conditional layout) is present but interleaved with marketing-flavored filler.

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?

No output schema exists, and the description does describe the return shape: shortlisting rows, the extra fields under compact:false, and the optional `look`/`terrain`/`layout`/`composition` members with their conditional presence. What a 'shortlisting row' actually contains is delegated to get_asset rather than spelled out, which leaves a small gap.

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 100%, so baseline is 3, but the description adds real meaning: compact:false is framed as get_asset-equivalent detail with a size warning, and it states that neither mode is needed if the goal is to build the place. The `id` parameter is only touched lightly (implied to come from list_kits via the schema), which keeps it from a 5.

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?

Opens with a specific verb and resource: every published part of one kit returned as shortlisting rows, plus the compact:false variant. It explicitly differentiates from siblings by naming get_asset (detail parity) and build_the_whole_place (assembly), so an agent can place it immediately.

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?

Gives positive conditions (compose a whole scene from one call, works on kits still filling up), an explicit negative routing ('To BUILD that place, do not read the rows: build_the_whole_place'), and a recommendation rule ('recommend its parts rather than the kit'). Alternatives are named, not implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources