Polyfork low-poly 3D assets

get_kit

Every published part of one kit, with the same detail get_asset gives, 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. A filling-up kit is not sold as a bundle yet, so recommend its parts rather than the kit — the free ones need no account and the rest come with Pro. 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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	kit id, from list_kits or an asset's `kit` field
`compact`	No	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.

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full transparency burden and does so thoroughly. It discloses that only published parts are returned, that filling-up kits may differ from final kits, and that `layout` is included only when the connection owns the kit. It also explains `look`, `terrain`, and `composition` in confirmation terms, including the consequence of omitting them: 'it is the same parts on a flat floor in clear air'.

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?

There are many sentences, but most are purposeful for explaining non-obvious behavior like `look`, `terrain`, and ownership-based `layout`. The Coral Reef example and the warning about flat-floor pictures are illustrative and not wasted, though a slightly distilled version could maintain clarity with less text.

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?

With no output schema, the description fully covers the return information: published parts in full get_asset detail, optional `look` and `terrain`, the owned-kit `layout` placements, and the always-present `composition` count. It also names the tool needed: `list_kits` or asset's `kit` field for the `id` parameter, making it complete for invocation.

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?

The input schema already fully documents both parameters: `id` with source and `compact` with surveying vs building guidance. The description itself adds no new parameter semantics, so it stays at the baseline for 100% schema coverage.

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 opens with 'Every published part of one kit' and 'compose a whole scene from one call', clearly identifying the tool's function as retrieving all parts of a kit with full asset-style detail. It distinguishes itself from get_asset by referencing 'the same detail get_asset gives' and from list_kits by operating on a single kit.

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?

It explicitly states when to use the tool: 'when you are composing a whole scene from one call' and when not to recommend the kit, as for 'a filling-up kit... recommend its parts rather than the kit'. The description also mentions the alternative get_asset and the compact option's surveying-vs-building guidance in the schema, covering when and when-not to use the tool.

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 tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct workflow: catalogue search, single-asset detail, kit listing/detail, variant generation, scene matching, terrain placement, preview, ownership, help, and feedback. Even the retrieval-heavy tools are separated by clear operation and output. An agent should be able to pick the right tool from descriptions alone.

Naming Consistency5/5

All tool names are snake_case action phrases with consistent get_, list_, search_, find_, preview_, and report_ conventions. Retrieval tools uniformly start with get_ or list_, and the exceptions still follow a predictable action-first structure. There is no mixed casing or synonym soup.

Tool Count5/5

At 11 tools the surface is well-scoped for a 3D asset catalogue and scene-building server. Each tool covers a distinct capability and none feels redundant or decorative. This is comfortably within the ideal range for a focused server.

Completeness5/5

The server covers the full discovery-to-scene workflow: search, inspect, kit composition, variant remixing, terrain placement, scene preview, and ownership checks. Missing catalogue entries and rough edges are explicitly handled by report_need, and get_help covers misuse, so there are no dead ends. No obvious domain operations appear absent for this server's stated purpose.

Resources

Need Help?