Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

generate_texture

Destructive

Create UV-mapped textures for untextured 3D meshes from text descriptions using cloud AI; requires a Meshy API key and internet.

Instructions

Cloud AI texture generation (requires Meshy API key + internet).

        For instant offline textures without any API, use
        ``apply_procedural_texture`` (multicolor) or
        ``apply_geometric_texture`` (relief) from kiln-pro.

        Takes any untextured mesh (STL, OBJ, GLB) and generates a
        UV-mapped texture based on the text description.  The textured
        model can then be processed with ``auto_multicolor_from_texture``
        (Kiln Pro) for multi-material printing.

        Requires a Meshy API key (``KILN_MESHY_API_KEY``).

        Args:
            mesh_path: Absolute path to the mesh file (STL, OBJ, GLB, FBX).
            prompt: Text description of the desired texture (max 600 chars).
                E.g. "smooth matte wood grain with dark walnut finish".
            style: Art style — ``"realistic"`` (default) or ``"2.5d-cartoon"``.
            provider: Generation provider.  Currently only ``"meshy"`` supports
                retexturing.

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": {
      "mesh_path": "<mesh_path>",
      "prompt": "<prompt>"
    },
    "name": "generate_texture"
  }
}

Input Schema

NameRequiredDescriptionDefault
styleNoArt style — ``"realistic"`` (default) or ``"2.5d-cartoon"``. Default: "realistic".
promptYesText description of the desired texture (max 600 chars). E.g. "smooth matte wood grain with dark walnut finish".
providerNoGeneration provider. Currently only ``"meshy"`` supports retexturing. Default: "meshy".
mesh_pathYesAbsolute path to the mesh file (STL, OBJ, GLB, FBX).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • addedInput schema / properties / mesh_path / description
      Added value: +"Absolute path to the mesh file (STL, OBJ, GLB, FBX)."
    • addedInput schema / properties / prompt / description
      Added value: +"Text description of the desired texture (max 600 chars). E.g. \"smooth matte wood grain with dark walnut finish\"."
    • changedInput schema / properties / provider / description
      Previous value: -"Default: \"meshy\"."New value: +"Generation provider.  Currently only ``\"meshy\"`` supports retexturing. Default: \"meshy\"."
    • changedInput schema / properties / style / description
      Previous value: -"Default: \"realistic\"."New value: +"Art style — ``\"realistic\"`` (default) or ``\"2.5d-cartoon\"``. Default: \"realistic\"."
  2. Changed4 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: -"realistic"
    • addedInput schema / properties / style / description
      Added value: +"Default: \"realistic\"."
  3. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description adds genuinely useful context the annotations lack: the cloud/API-key dependency, the internet requirement, and the supported mesh formats. However, it never explains what makes the call destructive — whether it overwrites the source mesh, writes a sidecar file, or where the textured result lands — and gives no sense of latency or quota/cost for a paid cloud call. Useful additions, but the key risk behavior remains undisclosed.

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 opening lines are well front-loaded — purpose, prerequisite, and alternative in the first two sentences — but roughly a third of the text is a reST "Args:" block that duplicates the input schema word for word and does not earn its place. Backtick markup also adds noise without information.

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?

There is no output schema, and the description never says what the call returns or where the generated texture/model is written, which matters for a destructive cloud generation tool an agent must chain into auto_multicolor_from_texture. The dependency and input requirements are complete, but the result contract is left implicit.

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%, and the "Args:" block restates the schema almost verbatim (mesh_path formats, the 600-char prompt limit, the style values, the meshy-only provider), so it adds little meaning beyond structured data. The only extra signal is the environment variable name KILN_MESHY_API_KEY, which is not itself a parameter. Baseline 3 is appropriate when the schema already carries the parameter semantics.

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 first sentence states a specific verb and resource ("Cloud AI texture generation") with its hard prerequisite, and the second explicitly routes to the offline siblings: apply_procedural_texture (multicolor) and apply_geometric_texture (relief). It also states the accepted inputs (STL, OBJ, GLB) and the outcome (UV-mapped texture from a text prompt), so an agent can distinguish it from every nearby texture sibling without opening a schema.

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

Usage Guidelines5/5

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

Guidance is explicit in both directions: use this when you need AI retexturing and have a Meshy key plus internet; use the named procedural/geometric tools when you want instant offline texture with no API. It also names the natural follow-on step (auto_multicolor_from_texture) for multi-material printing, so the position of this tool in a workflow is unambiguous.

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