forge3d-mcp

Create Shape

create_shape

Build a 3D mesh from a mathematical equation, control detail via resolution, and export it to GLB, STL, OBJ, PLY, OFF, glTF, or DAE for game, print, or web use.

Instructions

Build a shape from a mathematical equation and export it to any mesh format.

Pick a family with list_shapes, then pass the numbers. Everything is deterministic: the same shape and params give the same mesh every time.

resolution controls detail (12-512). It is the one knob you usually need — raise it for a hero asset, lower it for a game prop or a phone scene.

export_format: glb (default, web), stl (print), obj, ply, off, gltf, dae. GLB and STL are always written; export_format adds one more.

Shapes marked closed: false (mobius, helicoid, catenoid) are open surfaces — visually correct, but not printable solids. validate_model will say so.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_shape"
  }
}

Input Schema

Name	Required	Default
`name`	No
`shape`	No	supershape
`params`	No
`purpose`	No	game
`resolution`	No
`make_viewer`	No
`poly_budget`	No
`export_format`	No	glb
`render_previews`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.7Nov 4, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does disclose real behavior: determinism of output, that GLB and STL are always written while export_format adds a third file, and that closed:false shapes are open surfaces that won't print. It does not cover where files land, overwrite behavior, or cost of make_viewer/render_previews.

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?

Paragraphs are short and front-loaded, with the essential workflow first and the format table after. A few lines (the 'Everything is deterministic' aside, the phone-scene example) are nice-to-have rather than load-bearing, but nothing is bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, but for a 9-parameter, zero-annotation mutation-style tool the description leaves half the knobs undefined, including the poly_budget that interacts with resolution. It is adequate for a first call and not sufficient for confident tuning.

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 0% across 9 parameters, so the description must compensate and only partly does: resolution is documented with its 12-512 range and role, export_format is enumerated with defaults, and the open-surface caveat applies to specific shape names. name, purpose, poly_budget, make_viewer, render_previews, and the internal structure of params are left entirely to guesswork.

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 opening sentence gives a specific verb and resource ('Build a shape from a mathematical equation') plus the outcome ('export it to any mesh format'), which separates it from siblings like create_model or create_planet. The pointer to list_shapes for families makes the intent unambiguous.

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?

It establishes a clear workflow prerequisite ('Pick a family with list_shapes, then pass the numbers') and names validate_model as the check for printability. It does not, however, say when to choose this over create_model or create_planet, so selection among the creation siblings is still inferred.

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