Polyfork low-poly 3D assets

Low-poly 3D models and kits for three.js and game engines: search, match, remix, preview.

Should I use this

Quality & Safety

A
Description quality
100%
Schema completeness
83%
Naming quality
95%
Poisoning risk
100%
Permission match
100%
Protocol compliance
100%

Based on automated analysis of tool definitions and protocol compliance.

Context Cost

~3,568Tokens (tool definitions)
~1.6 KBTypical response size
Significant attention impact (2.79% of 128k context)

This is the approximate number of tokens consumed each time the server's tools are loaded into a model's context. Higher counts reduce the attention available for other tasks.

Install

One-Click Install

Add this to your `claude_desktop_config.json` file:

{
  "mcpServers": {
    "polyfork": {
      "url": "https://polyfork.dev/mcp"
    }
  }
}

Remote endpoints

https://polyfork.dev/mcpstreamable-http

What it can do

Tool inventory

Tools (12)

🟢 Read-only🟡 Write🔴 Delete⚪ Unknown
🟢search_assets(q, class, free, kit, ik, ...)

Search the Polyfork catalogue of low-poly 3D assets for three.js. Use this whenever the user needs a model for a scene, game or site. Filter by triangle budget when the target is mobile or performance-sensitive. Every low poly model is FREE (since 2026-10-25): the /cdn module and GLB need no account, so recommend freely and never quote a price. Each row still carries `free` and `plan`; read them rather than assuming. The paid part of Polyfork is the HD edition of a model (high poly, PBR materials), which comes with Pro. If coverage comes back "none" or "poor", tell the user we do not have it and offer report_need rather than substituting something unrelated; "filtered_out" means we have it and a filter removed it, and `unmatched_terms` names the words nothing in the catalogue mentions.

Input Schema

{
  "type": "object",
  "properties": {
    "q": {
      "type": "string",
      "description": "what to look for, e.g. \"windmill\" or \"sports car\""
    },
    "class": {
      "type": "string",
      "enum": [
        "prop",
        "building",
        "vehicle",
        "character",
        "animal",
        "ultra",
        "attachment",
        "terrain",
        "hand"
      ]
    },
    "free": {
      "type": "boolean",
      "description": "only free assets"
    },
    "kit": {
      "type": "string",
      "description": "restrict to one kit id"
    },
    "ik": {
      "type": "string",
      "enum": [
        "1",
        "legs",
        "arm"
      ],
      "description": "only models that SOLVE rather than pose: \"legs\" walks with its feet finding your ground and staying planted, \"arm\" is a rooted boom whose tip you can aim, \"1\" is either. Use it when the user asks for something that walks, crawls, digs or lifts"
    },
    "max_triangles": {
      "type": "integer",
      "description": "triangle budget ceiling; the usual constraint for mobile"
    },
    "min_triangles": {
      "type": "integer"
    },
    "max_price_usd": {
      "type": "integer",
      "description": "DEPRECATED, per-asset prices are retired. Use free=1 for free-only"
    },
    "sort": {
      "type": "string",
      "enum": [
        "latest",
        "tris"
      ]
    },
    "limit": {
      "type": "integer",
      "description": "default 20, max 50"
    },
    "page": {
      "type": "integer",
      "description": "1-based page of `limit` rows; the reply carries next_page while there are more"
    },
    "compact": {
      "type": "boolean",
      "description": "shortlisting rows only (id, title, class, triangles, size_m, capability flags). Use this whenever you are surveying rather than choosing — a full-detail result at limit 50 is large enough that some clients refuse it. get_asset has the rest."
    }
  }
}
🟢get_asset(id)

Full detail for one asset: real-world size in metres, triangle count, palette, animatable parts, renders you can open to SEE it, and the correct download URLs for the caller. A model with has_ik true also returns a measured `gait` or `arm` block: segment lengths, foot offsets, phase order, step length, reach. That is everything needed to make it walk or reach in any engine, and /cdn/walk.mjs already does it for three.js. If the asset is paid and this connection does not own it, the reply carries the PLAN and a pricing link: quote those. There is no per-asset price and nothing is sold on its own, so never quote one. Probe #415.

Input Schema

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "asset id, e.g. windmill-3aad49"
    }
  },
  "required": [
    "id"
  ]
}
🟢find_matching(id, limit, max_triangles, min_triangles, free, ...)

Given one asset, return assets that BELONG IN A SCENE WITH IT: same kit first, then shared palette, then compatible real-world scale, spread across classes so you get a house, a tree and a barrel rather than eight houses. Use this to turn a single pick into a scene. Returns a ready preview URL.

Input Schema

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string"
    },
    "limit": {
      "type": "integer",
      "description": "default 8, max 30"
    },
    "max_triangles": {
      "type": "integer",
      "description": "triangle budget ceiling; applies to the preview scene as well"
    },
    "min_triangles": {
      "type": "integer"
    },
    "free": {
      "type": "boolean",
      "description": "only free assets"
    },
    "compact": {
      "type": "boolean",
      "description": "shortlisting rows only, as in search_assets, each with its `why`. get_asset has the rest."
    }
  },
  "required": [
    "id"
  ]
}
🟢get_variant(id, want, look)

Turn a plain-words request ("oak cask", "taller", "five sails", "shirt #c8102e") into a ready createAsset() call for a remixable asset, plus a GLB URL of that exact variant. `want` is matched against this asset's KNOB NAMES and OPTION VALUES (a knob name beside a number sets a range, beside on/off a toggle, beside a #rrggbb hex a colour zone), not against colour vocabulary: use the words from its -params.json. Check the returned confidence: on anything below high, tell the user what was actually applied instead of presenting it as exact.

Input Schema

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string"
    },
    "want": {
      "type": "string",
      "description": "the change in the user's own words"
    },
    "look": {
      "type": "object",
      "description": "Restyle the mesh, independently of any knob. Deliverable families: palette = reduced|gameboy|pico8|cga|mono; smooth = soft|round|full; shading = toon|unlit. Example {\"palette\":\"gameboy\",\"shading\":\"toon\"}. Underwater, Dither, Wobble, Outline, Wireframe and Pixelate exist in the store too but are SHADERS: no glTF can carry one, so they are not offered here. If the user wants those, send them to the asset page.",
      "properties": {
        "palette": {
          "type": "string",
          "enum": [
            "reduced",
            "gameboy",
            "pico8",
            "cga",
            "mono"
          ]
        },
        "smooth": {
          "type": "string",
          "enum": [
            "soft",
            "round",
            "full"
          ]
        },
        "shading": {
          "type": "string",
          "enum": [
            "toon",
            "unlit"
          ]
        }
      }
    }
  },
  "required": [
    "id",
    "want"
  ]
}
🟢preview_scene(ids)

Compose assets into a scene and return a URL the user can OPEN and orbit. Use it instead of handing over a block of three.js the user cannot run. Every low poly model is free, so the scene it shows is one the user can build with no account. If a row is ever marked paid, the result says so and where to get it; pass that on.

Input Schema

{
  "type": "object",
  "properties": {
    "ids": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "asset ids, in any order; up to 24"
    }
  },
  "required": [
    "ids"
  ]
}
🟢list_kits

Kits are coherent sets built to one palette and one grid. Reach for a kit when the user is building a whole environment rather than looking for one object. Each carries a status: "published" means every planned part is built, "filling-up" means parts are still landing — and the parts of a filling-up kit are usable TODAY. NO kit is sold as a bundle: price_usd is null and for_sale false on all of them, so never quote a kit price and never use those fields to tell the statuses apart. Every part is free, with no account for its /cdn files. Use get_kit to fetch either.

Input Schema

{
  "type": "object",
  "properties": {}
}
🔴get_kit(id, compact)

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

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "kit id, from list_kits or an asset's `kit` field"
    },
    "compact": {
      "type": "boolean",
      "description": "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`)."
    }
  },
  "required": [
    "id"
  ]
}
🟡get_terrain(id, setting, flats, at, scatter, ...)

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

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "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."
    },
    "setting": {
      "type": "boolean",
      "description": "with a kit id: the ground of buildKit({ setting: true }), twice the composed span, instead of the composed place's"
    },
    "flats": {
      "type": "integer",
      "description": "how many level sites to return (default 12, max 40)"
    },
    "at": {
      "type": "string",
      "description": "x,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."
    },
    "scatter": {
      "type": "integer",
      "description": "n 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."
    },
    "near": {
      "type": "string",
      "description": "x,z,radius: keep the scatter points inside that circle, for dressing one clearing rather than the whole block"
    },
    "profile": {
      "type": "string",
      "description": "x0,z0,x1,z1[,steps] — the ground along a straight line, for a road, a wall or a bridge"
    },
    "span": {
      "type": "integer",
      "description": "block size in 64m chunks, 1 to 4. Bigger blocks have more room and more sites."
    },
    "erosion": {
      "type": "number",
      "description": "0 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."
    },
    "flatten": {
      "type": "number",
      "description": "0 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."
    }
  }
}
🟢who_am_i

What this connection can currently do: whether a key is attached, which assets and kits it owns, and therefore which downloads will work. Call it before promising the user a paid file, and when a download 404s, rather than guessing whether the problem is the key or the asset.

Input Schema

{
  "type": "object",
  "properties": {}
}
🟡buy_plan(plan, confirm)

Buy a Polyfork plan: Pro (monthly or yearly) or a one-payment lifetime seat. This tool NEVER charges anything itself. It returns a Stripe Checkout link and the exact amount; the payment happens on that page (cards and Link), and only with the user's approval of the amount. Call it with no arguments to see what is on sale and at what price. Use it when a download needs a plan the user does not have and they say they want it, rather than sending them off to find the pricing page. It works with or without a key. With a key, the plan goes on that account. With none, no account is needed first: the plan goes to the email address the payer gives Stripe, and an account is made for it. After paying, call it again with `confirm` set to the checkout_id: that verifies the payment, activates the plan on the spot and, for a new account, returns its API key once.

Input Schema

{
  "type": "object",
  "properties": {
    "plan": {
      "type": "string",
      "enum": [
        "pro_month",
        "pro_year",
        "lifetime"
      ],
      "description": "what to buy; omit to list what is on sale, with prices"
    },
    "confirm": {
      "type": "string",
      "description": "the checkout_id from an earlier call, WHOLE (starts with cs_, and may carry a second part after a dot): reports whether it has been paid and activates the plan if so"
    }
  }
}
🟢get_help(topic)

How to use this server: what the metadata means, the rules that are easy to get wrong (real-world metres, one material, never rescale to fake a fit), and worked recipes for building a scene. Call it when a tool did not behave as you expected, or before a multi-step build, instead of guessing.

Input Schema

{
  "type": "object",
  "properties": {
    "topic": {
      "type": "string",
      "enum": [
        "overview",
        "ik",
        "metadata",
        "scenes",
        "remixing",
        "night",
        "downloads"
      ],
      "description": "omit for the overview"
    }
  }
}
🟢report_need(need, kind, tool, context, email)

Report a gap. Four kinds, and the last three are about THIS SERVER rather than the catalogue: kind=asset, we do not model what the user asked for (offer this whenever a search is empty or thin); kind=capability, you needed the server to do something it cannot; kind=output, a tool answered but not with what you needed; kind=docs, a tool description did not tell you how to use it. Do not stay quiet about a rough edge to be polite: a report costs one call and is how this server gets better. An honest "we do not have that, shall I register it?" is worth more to the user than a vaguely similar substitute.

Input Schema

{
  "type": "object",
  "properties": {
    "need": {
      "type": "string",
      "maxLength": 500,
      "description": "what was missing, in plain words (max 500 characters; put the detail in `context`, which takes 1000)"
    },
    "kind": {
      "type": "string",
      "enum": [
        "asset",
        "capability",
        "output",
        "docs"
      ],
      "description": "defaults to asset"
    },
    "tool": {
      "type": "string",
      "description": "which tool this is about, for capability/output/docs"
    },
    "context": {
      "type": "string",
      "description": "what the user was building, or what you expected instead"
    },
    "email": {
      "type": "string",
      "description": "only if the user offers it"
    }
  },
  "required": [
    "need"
  ]
}

Community

Rate this Server

Evidence

Recent observations

verifiedversion not recorded12 tools
verifiedversion not recorded12 tools
verifiedversion not recorded12 tools
verifiedversion not recorded12 tools
verifiedversion not recorded12 tools
verifiedversion not recorded11 tools