forge3d-mcp

Create Model

create_model

Generate a 3D model from a prompt, spec, or source code, then receive the mesh, validation report, and shareable viewer link for checking and handing off the result.

Instructions

Generate a 3D model and return its card, validation report and viewer link.

backend='auto' routes from the spec; pass an explicit engine when you know better. source is the code that builds the model for the code backends: procedural — python defining build() -> trimesh object openscad — OpenSCAD CSG source blender — a bpy script cadquery — python assigning result hosted — optional prompt override for a text-to-3D service

Returns path (the mesh), viewer (a single-file HTML page you can hand to anyone) and validation. Always read validation.ok before calling it done.

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_model"
  }
}

Input Schema

Name	Required	Default
`mode`	No	auto
`name`	No	model
`seed`	No
`style`	No
`units`	No	mm
`prompt`	No
`source`	No
`backend`	No	auto
`purpose`	No	any
`materials`	No
`dimensions`	No
`references`	No
`constraints`	No
`make_viewer`	No
`poly_budget`	No
`scale_to_spec`	No
`idempotency_key`	No
`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

B3.3/5.0

Behavior3/5

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

With no annotations at all, the description carries the full burden, and it does disclose useful behavior: backend routing logic, per-backend meaning of source, and the returned artifacts (path, viewer, validation). It does not cover side effects such as whether files are written to disk, whether the operation is long-running or job-based (the presence of get_job/list_jobs siblings hints at async but the description is silent), or cost/time expectations for hosted backends.

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 first sentence front-loads purpose and outputs, then the per-backend source block is compact and scannable. Wording is tight with no filler. The inline backticked bullets are slightly dense but every line conveys distinct information.

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

Completeness2/5

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

Output schema exists, so return-value explanation is optional and the description's coverage of path/viewer/validation is a bonus. However, for an 18-parameter, zero-coverage, unannotated creation tool, essential context is missing: valid mode values, whether the call is synchronous or produces a job id, idempotency_key behavior, and what poly_budget/scale_to_spec actually constrain.

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 description coverage is 0% across 18 parameters, so the description must compensate and largely does not. It explains backend and source well, including the distinct contract for procedural, openscad, blender, cadquery, and hosted source values, which is genuinely valuable. But mode, seed, style, units, purpose, materials, dimensions, references, constraints, make_viewer, poly_budget, scale_to_spec, idempotency_key, and render_previews receive no explanation, leaving most of the surface undocumented in both schema and prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Generate a 3D model and return its card, validation report and viewer link.' That is concrete enough to separate it from inspect_model, validate_model, and render_model. It stops short of naming which sibling to prefer for planning versus creation (plan_model, create_shape, create_planet), so the boundary is inferable rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives workflow guidance within a call ('always read validation.ok before calling it done') and a rule for choosing backend values ('auto routes from the spec; pass an explicit engine when you know better'). It never says when to use create_model instead of plan_model, create_shape, or create_planet, nor what prerequisites exist, so selection between siblings is left to inference.

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