Skip to main content
Glama

generate_model_from_image

Destructive

Convert a reference image into a 3D model for printing or design iteration, using agent vision by default or Meshy when an API key is configured.

Instructions

Make a 3D model from a reference image.

        DEFAULT (keyless): you (the agent) can SEE the image — study it,
        give it to ``design_session`` as ``reference_images`` (every later
        make is checked against it), and write the OpenSCAD yourself for
        ``design_session(verb="generate", scad_code=...)`` — or
        ``compile_scad`` on an install without ``design_session``. You do
        NOT need an image-to-3D provider, and with no key configured this
        tool hands the job back to your vision instead of erroring.

        OPT-IN cloud path: when the user has set their OWN
        KILN_MESHY_API_KEY, this submits the image to Meshy for an AI mesh
        reconstruction. The image should show the object clearly against a
        clean background for best results.

        **EXPERIMENTAL:** AI-generated models are experimental.  Always
        validate the mesh before printing.

        ``reference_picture`` says what becomes of the picture: compared
        with the model when it arrives and with every make on the goal it
        is given to, or, where this install cannot compare, that you must.

        **Image tips:**
        - Use a clear, well-lit photo of the object.
        - Plain/solid backgrounds produce better results.
        - Show the full object — avoid cropped or partial views.
        - Multiple angles are not supported; use the best single view.

        Args:
            image_url: URL to the reference image (PNG, JPG).  Must be
                publicly accessible.
            provider: Generation provider.  Currently only ``"meshy"``
                supports image-to-3D.
            style: Optional style hint (``"realistic"`` or ``"sculpture"``).

MAKE DOORS: design_session, Kiln's front door for making an object, is not installed here (signed in to Kiln it runs on Kiln's servers). On this install compile_scad IS the make → preview → iterate loop: make it, show the preview, iterate.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "image_url": "<image_url>"
    },
    "name": "generate_model_from_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
styleNoOptional style hint (``"realistic"`` or ``"sculpture"``).
providerNoGeneration provider. Currently only ``"meshy"`` supports image-to-3D. Default: "meshy".
image_urlYesURL to the reference image (PNG, JPG). Must be publicly accessible.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • addedInput schema / properties / image_url / description
      Added value: +"URL to the reference image (PNG, JPG).  Must be publicly accessible."
    • changedInput schema / properties / provider / description
      Previous value: -"Default: \"meshy\"."New value: +"Generation provider.  Currently only ``\"meshy\"`` supports image-to-3D. Default: \"meshy\"."
    • addedInput schema / properties / style / description
      Added value: +"Optional style hint (``\"realistic\"`` or ``\"sculpture\"``)."
  2. Changed3 schema fields changedv1.5.0
    • removedInput schema / properties / provider / default
      Removed value: -"meshy"
    • addedInput schema / properties / provider / description
      Added value: +"Default: \"meshy\"."
    • removedInput schema / properties / style / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is partly covered. The description adds that AI models are experimental and must be validated before printing, and that keyless mode hands work back to vision instead of erroring, but it never explains what makes the tool destructive, whether credits are consumed, or what artifacts are produced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and separates default, opt-in, and experimental notes, but it is verbose and includes a confusing paragraph about 'reference_picture' that does not match any actual parameter. The trailing 'MAKE DOORS' note is relevant but awkwardly appended rather than integrated.

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?

For a complex image-to-3D tool with no output schema, the description covers modes, image tips, experimental warnings, and installation context well. However, it does not explain what the tool returns (e.g., a mesh file, a job ID, or a status), which is a meaningful gap for an agent trying to invoke and follow up on it.

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 100%, so the schema already documents image_url, provider, and style. The description reinforces public accessibility of the image and the values accepted by provider/style, but it adds little meaning beyond the structured schema and even references a nonexistent 'reference_picture' parameter.

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?

The description opens with a specific verb and resource: 'Make a 3D model from a reference image.' It explains the two modes (keyless vision handoff vs. Meshy cloud reconstruction) but does not explicitly compare itself to sibling tools like generate_model or generate_model_with_provider, leaving some ambiguity around image-to-3D versus generic generation.

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 gives explicit when-to-use guidance: use the keyless path by default, opt into the cloud path only when KILN_MESHY_API_KEY is set, and defer to design_session or compile_scad when appropriate. The later 'MAKE DOORS' note clarifies that design_session is not installed here, though that creates a slight tension with the earlier instruction to use design_session.

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