Skip to main content
Glama

Polyfork low-poly 3D assets

by dev.polyfork

search_assets

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. Results mix FREE and PRO assets: each carries free and plan. Paid assets are not sold individually — they come with Pro or the one-time Founders plan — so quote the plan, never a per-asset price. you should say which is which when recommending one, rather than letting the user discover it at download time. If coverage comes back "none" or "poor", tell the user we do not have it and offer report_need rather than substituting something unrelated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNowhat to look for, e.g. "windmill" or "sports car"
ikNoonly 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
kitNorestrict to one kit id
freeNoonly free assets
sortNo
classNo
limitNodefault 20, max 50
compactNoshortlisting 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.
max_price_usdNoDEPRECATED, per-asset prices are retired. Use free=1 for free-only
max_trianglesNotriangle budget ceiling; the usual constraint for mobile
min_trianglesNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / class / enum
      Previous value: -[
-  "prop",
-  "building",
-  "vehicle",
-  "character",
-  "animal",
-  "ultra",
-  "attachment",
-  "terrain"
-]New value: +[
+  "prop",
+  "building",
+  "vehicle",
+  "character",
+  "animal",
+  "ultra",
+  "attachment",
+  "terrain",
+  "hand"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / class / enum
      Previous value: -[
-  "prop",
-  "building",
-  "vehicle",
-  "character",
-  "ultra",
-  "attachment",
-  "terrain"
-]New value: +[
+  "prop",
+  "building",
+  "vehicle",
+  "character",
+  "animal",
+  "ultra",
+  "attachment",
+  "terrain"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / class / enum
      Previous value: -[
-  "prop",
-  "building",
-  "vehicle",
-  "character",
-  "ultra",
-  "attachment"
-]New value: +[
+  "prop",
+  "building",
+  "vehicle",
+  "character",
+  "ultra",
+  "attachment",
+  "terrain"
+]
  4. First observed

TDQS

A4.3/5.0
Behavior5/5

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

With zero annotations, the description carries the full burden and delivers: results mix FREE and PRO assets and each carries `free` and `plan`; paid assets are not sold individually so the agent must quote a plan, never a per-asset price; the agent must disclose free-versus-pro when recommending; and coverage "none"/"poor" has a defined fallback. This prevents exactly the high-cost errors (misquoting prices, recommending unavailable items) that annotations would otherwise have to cover. It is also consistent with the deprecated max_price_usd param noting per-asset prices are retired.

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?

The core purpose is front-loaded in the first sentence, and each subsequent block (trigger, triangle filter, pricing model, coverage fallback) earns its place — the pricing rule is critical context. Slight redundancy between "Results mix FREE and PRO assets" and "Paid assets are not sold individually," and the lowercase "you should" breaks flow, but the length is justified by the domain complexity.

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?

For an 11-parameter tool with no output schema and no annotations, the description covers the critical domain traps: the free/pro result mix, the plan-not-per-asset pricing rule, the disclosure obligation, and the report_need fallback for poor coverage. The compact param partially sketches result fields, though the full-detail return shape and pagination behavior are not described. Nearly complete for a search tool of this complexity.

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 73%, so the schema already documents most parameters. The description adds genuine value by tying the triangle-budget parameters to the mobile/performance-sensitive use case. However, sort, class, and min_triangles remain undocumented in both schema and description, and the description does not compensate for those gaps — an adequate but not compensating score.

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?

"Search the Polyfork catalogue of low-poly 3D assets for three.js" names a specific verb, resource, and domain. The trigger "Use this whenever the user needs a model for a scene, game or site" clearly positions it as the catalogue search entry point, distinguishing it from sibling retrieval tools like get_asset, get_kit, and get_terrain.

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?

The description gives an explicit trigger condition (user needs a model for a scene/game/site), a specific filtering rule (triangle budget for mobile/performance-sensitive targets), and an explicit alternative routing: offer report_need when coverage is "none" or "poor" rather than substituting. Missing an explicit when-not-to-use against siblings such as get_asset for an already-identified asset, so it stops short of a 5.

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
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.3/5.0
Disambiguation5/5

Each tool has a clearly distinct responsibility: searching the catalogue, inspecting a single asset, expanding into a compatible scene, managing kits, placing objects on terrain, generating variants, previewing scenes, checking ownership, and reporting gaps. Even the meta tools (get_help, report_need, who_am_i) are cleanly separated from the asset-workflow tools.

Naming Consistency4/5

The naming is largely consistent snake_case with an action_noun shape: get_asset, get_kit, get_terrain, list_kits, search_assets, preview_scene. Minor deviations like find_matching and who_am_i still read clearly and do not create confusion.

Tool Count5/5

Eleven tools is a well-scoped count for a 3D asset catalogue server that also handles scene composition, terrain, variants, previews, and account context. Each tool earns its place and none feel redundant or like filler.

Completeness5/5

The surface covers the full workflow from searching and inspecting assets, through variants and kits, to scene placement, terrain height queries, previews, and ownership checks. Meta tools for help and reporting gaps also close the loop, so an agent is unlikely to hit a dead end.

Resources