Skip to main content
Glama
Sign In
paprika3d

paprika3d

Official
by Keeno-Corp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

model_run

Execute JavaScript against a persistent three.js scene to build 3D models in code and save them as .glb files for your project.

Instructions

Runs JavaScript against the modelling scene: a three.js scene this server keeps between calls, apart from any page, for building a model in code as in Blender, then saving it as a .glb the page loads. The code is an async function body with THREE, scene, geo (Manifold, started: geo.Manifold, geo.CrossSection, geo.toGeometry(manifold), geo.toManifold(geometry), geo.boolean(op, a, ...b)), scatter, find(name), stats(target) (vertices, triangles, bounds, closed, volume, genus per mesh), load(path) (a .glb from the project, an asset_search pick included, added to the scene and returned), save(path, object = scene) (a GLB under cwd; replies with its size and the line that loads it) and clear() in scope, and returns what it returns, as JSON, with up to 5 lines it logged. What it adds to scene stays for the next call and is saved to paprika3d/model/scene.glb after each run that changed it, so a restart loads it back; variables (a Manifold) do not last between calls. Manifold works in metres with Z up and angles in degrees; three is Y up. Name every object you make: model_look lists them by name.

Input Schema

NameRequiredDescriptionDefault
cwdYesThe game project's folder.
codeYesAn async function body, e.g. `const { Manifold, toGeometry } = geo; const m = Manifold.cube([1, 1, 1], true).subtract(Manifold.sphere(0.65, 48)); const mesh = new THREE.Mesh(toGeometry(m), new THREE.MeshStandardMaterial({ color: 0xb08050 })); mesh.name = "block"; scene.add(mesh); return stats(mesh)`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses the persistent scene, automatic saving to paprika3d/model/scene.glb after changing runs, non-persistence of variables, JSON return behavior, and the five-line log limit. It also states coordinate and unit conventions for Manifold versus three.js.

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 description is front-loaded and every sentence contains operational information needed to call the tool correctly. However, the long run-on sentence with nested parenthetical scope lists makes it denser and harder to scan than it could be.

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?

There is no output schema or annotations, so the description must be self-contained, and it is: it covers execution context, available globals, persistence semantics, return format, logging limits, save path, and unit conventions. An agent has enough information to invoke and interpret the tool without additional structured hints.

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 the baseline is 3, but the description adds substantial meaning beyond the schema by explaining the async function body environment, available scope objects, and return behavior. It adds less about cwd beyond the fact that saved GLBs go under it, so it falls short of a perfect 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?

The description states a specific verb and resource: it runs JavaScript against the server's persistent three.js modelling scene to build and save models. It also distinguishes the scene from page context and names model_look for listing created objects, so the tool's role is clear against siblings.

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 clear usage context: build a model in code as in Blender, then save it as a .glb the page loads. It references model_look for naming/listing objects, but it does not explicitly state when not to use this tool versus alternatives such as model_audit or other sibling tools.

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

Deploy Server

Other Tools