thicken
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| THICKEN_VISION_URL | No | With THICKEN_VISION_URL set, the photos themselves (re-encoded, so without their EXIF) go to that host for the vision models. A LAN server you control still forwards each photo to the model's provider; a hosted endpoint sees every photo. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| thicken_profilesA | Lists thicken's profiles: each kind of object it can make into a 3D model at its real size, what it is made from, what it makes, and what the vision models read off it. Call it to choose a profile for thicken_make, or to tell the user what thicken can make. |
| thicken_makeA | Turns photos of one real object (or artwork, or words, or a book's ISBN) into two files that belong together: a GLB model at the object's real size, in millimeters, and its metadata as JSON, read off it by vision models and looked up in public catalogs (thicken_profiles lists each kind of object and the metadata it records). Writes both files and returns their paths and the main facts. Photos need not be cropped when a vision roster is set up (THICKEN_VISION_URL, THICKEN_VISION_MODELS); without one, give straight-on photos cropped to the object, and name the profile. One object a call: for several, call once each. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
thicken_make and thicken_profiles have clearly distinct purposes: one generates a 3D model plus metadata, while the other only lists available profiles. There is no meaningful overlap that would cause an agent to misselect between them.
Both names use a consistent thicken_ prefix and snake_case, which is readable and predictable. The minor deviation is that thicken_make is action-oriented while thicken_profiles is resource-oriented, but the set is still coherent.
Only two tools are provided, making the surface quite thin even for a narrow generation workflow. Each tool has a clear role, but the set sits at the borderline of being too minimal.
The core workflow is covered: profiles help choose what can be made, and thicken_make creates the model plus metadata. Minor gaps exist around inspecting generated outputs or separately querying model details, but agents can work around them from the returned paths and facts.