Thicken’s MCP server lists its object profiles and creates real-size 3D GLB models with paired JSON metadata from photos, artwork, words, or ISBNs.
List supported profiles and what each records: badge, book, card, lettering, slab, and box.
Make a model for one object per call, either naming the profile or letting thicken infer it from codes or vision.
Accept photos, scanner PDFs, videos, typed words for lettering, or an ISBN for a book.
Use vision models for uncropped/angled inputs and public catalogs for ISBN lookups where configured.
Set real dimensions, slab holder, card thickness in points, badge/lettering width and depth, custom face corners, cropped-input mode, preview image, and output GLB path.
Write the GLB and sidecar JSON, returning their paths and the main extracted facts.
Supports vision analysis through any OpenAI-compatible endpoint to identify objects, locate and straighten faces, and read printed text from photos or video.
thicken turns photos of a real object into a GLB model at its real size and its metadata as JSON, read off the object by vision models and looked up in public catalogs. What it knows about each kind of object lives in a profile: a few come with thicken, and you can add your own.
The other half: its metadata. Part of the first one's, a graded Giannis Antetokounmpo card:
{
"profile": "slab",
"holder": "cgc",
"grader": "cgc",
"cert": "6072896005",
"widthMm": 80.5, "heightMm": 135, "depthMm": 7.5,
"read": {
"grade": "9", "gradeName": "MINT",
"autoGrade": "10", "autoGradeName": "AUTO",
"signed": "G. ANTETOKOUNMPO, 8/2/25",
"name": "Giannis Antetokounmpo", "year": "2024-25", "maker": "Panini",
"set": "Court Kings Basketball", "number": "#5", "variant": "Blank Slate"
},
"readBy": { "grade": "agreed", "autoGrade": "agreed", "set": "disputed" },
"inside": {
"card": { "widthMm": 63.5, "heightMm": 88.9, "corners": "square", "foil": "none" },
"label": { "widthMm": 66.4, "heightMm": 26.9 }
}
}The grader and certificate number come from the label's QR code; the vision models read the rest off the slab. What each profile records is in the table of profiles, and every field is described in USAGE.md.
Try it · From an AI agent · How it works · The thicken object · What it makes
In detail (USAGE.md): batch · photos · vision · video · training mode · review · the sidecar · previews · inputs · sizes
What leaves your machine · Adding a profile · Security · Built on · Development · License
Related MCP server: hy3d-mcp
npm install -g thicken # Node 22.18 or later; or npx thicken …
thicken photo.jpg # it works out what it is: a code on it, or the vision models
thicken book cover.heic back.heic spine.heic
thicken --isbn 9780061120084 # no photo: the cover and size from Open Library
thicken slab front.jpg back.jpg
thicken card front.jpg back.jpg --pt 130 # a thick patch card
thicken badge badge.png --width 50 # cut-out artwork, extruded
thicken lettering thicken # the logo
thicken batch ~/Pictures/books --preview # a model per photo, PDF, video or folderEach run writes <name>.glb and <name>.json beside the first picture, and
with --preview a picture of both sides. Photos straight on and cropped work
as they are; uncropped photos, angled shots and video need a vision roster,
any OpenAI-compatible endpoint (Vision). As a
library: import { thicken } from 'thicken', then thicken(files, options)
gives the GLB's bytes and the sidecar.
thicken is an MCP server too (thicken mcp), with an Agent Skill that tells
the agent when and how to use it: ask for a model of the book on your desk,
and the agent makes it. In Claude Code:
/plugin marketplace add bikemeardsley/thicken
/plugin install thicken@thickenOr for any MCP client, npx -y thicken mcp on stdio. Codex, Copilot,
Cursor, Antigravity, Gemini CLI and the rest are in USAGE.md.
What thicken knows about a kind of object lives in its profile: how to recognize it, its faces, what to read off it, and how to build it at its real size. A code on the object picks the profile (an ISBN barcode, a grader's QR code), or the vision models say which it is. thicken is not a photogrammetry tool: everything it handles is close to a box or a flat outline, so it builds the geometry from known sizes and maps your photos onto it.
What thicken makes is more than a 3D shape. Each run writes a thicken object: the model (a GLB at the object's real size, in millimeters) and, beside it, its metadata (the JSON sidecar), which knows what the object is, in its profile's own terms. For the profiles that come with thicken, for example:
A book: its ISBN, its catalog record (title, authors, publishers, dates, subjects, Dewey and Library of Congress classes, pages), and how sure the match is when it was found by title.
A graded slab: its grader, cert number and verification link, its holder, and the card and label inside it, each sized and placed. With vision, the label read: the card's grade (its number and words, "9 MINT", any qualifier and subgrades), an autograph's own grade when the label grades one apart from the card ("AUTO 10"), who signed it and when, and the card as the grader names it.
A raw card: its size, its thickness in points for a thick card, its corners and its foil. With vision, what's printed on it: player or character, team, year, maker, set, number, parallel.
A box: with vision, its name, brand, edition, rating and year.
A badge: with vision, what it names, who issued it, its level, subject, date, any credential number, and every other word on it.
Every object: what the vision models read off it, and how sure; which faces are your photos and which are stand-ins, how each fact was found, what is still worth photographing, and what each vision model answered.
An app shows the model and reads the sidecar: a library shelf of your books, a vault of your slabs. The fields are under What the sidecar records.
thicken makes the 3D object; what it knows about kinds of object lives in
profiles, one file each in src/profiles. Anyone can add one
(CONTRIBUTING.md). Every profile there today:
Profile | What it is | From | Makes | With vision, reads |
| cut-out digital artwork: a certification badge, logo or sticker design | Artwork with transparency around its shape ( | The artwork's own outline, extruded: the art on its face, its edge color on the sides and back | name, issuer, level, subject, date, id, text |
| a book, hardcover or paperback | Front cover, back, spine and page sides, in any order and any of them; or just an ISBN | The book at its real size, from its ISBN's catalog record: a paperback softly rounded, a hardcover with boards standing past its pages | title, subtitle, authors, series, publisher, edition |
| a single trading card on its own, not sealed in a plastic holder | Front, and its back | A thin plate, 63.5 × 88.9 mm unless | name, team, year, maker, set, number, variant |
| words made into puffy 3D bubble letters | Words, typed where pictures would go ( | Puffy gold bubble letters, round in section like a balloon, in the Titan One font | – |
| a graded trading card sealed in a clear plastic holder with a label | Front, and its back | A clear plastic holder at its grader's size, with the card and the grade label inside it, each cut from the photos | grader, grade, gradeName, qualifier, subgrades, autoGrade, autoGradeName, autograph, signed, cert, name, team, year, maker, set, number, variant |
| a box-shaped object (a game case, a phone, a deck of cards, packaging) | Front, and any of its back and sides; its size ( | A softly rounded box with the photos on its faces | title, brand, edition, rating, year |
What each one records in its sidecar, beside what every model has (its size and where it came from, its faces and pictures, its codes, what the vision models read and how sure, what's worth a second look: all in USAGE.md):
Field | What it holds |
| the color just inside its outline, used for its sides and back (#rrggbb) |
| how many separate shapes the artwork is (a medal and its ribbon are two) |
| where its width and depth came from: given, or the default (artwork carries no scale) |
Field | What it holds |
| its ISBN: given, read off its barcode, or from a title match with one edition |
| Open Library's record of the edition and its work: title, authors, publishers, dates, edition, format, series, languages, subjects, Dewey and LC classes, contents, every id, links, cover |
| when found by the title read off it: what was read, how sure the match is, the work and its editions |
| its page count |
| hardcover or paperback |
| how that was found: vision, catalog or assumed |
| where each of its sizes came from: measured, openlibrary, loc, googlebooks, pages, photos, cover or trim |
| every thickness estimate made: from the photos and from the page count |
| Open Library's cover, when it stands in for a front not photographed |
| where a foil seal or sticker is on its front cover, and whether it's round |
| its page edges' color (#rrggbb), whether gilt, and how found: photo (a photo shows them), vision (the models' colors) or assumed (cream) |
| its cover's finish: glossy or matte |
| how that was found: vision or assumed |
| every catalog request: host, path, status and time |
Field | What it holds |
| how its corners are cut: square, slight or round |
| how that was found: vision or assumed |
| its foil: none, holo (the picture shines), reverse (all but the picture) or full |
| how that was found: vision or assumed |
| its foil's pattern, when it shines (src/patterns.ts): "shards", "flow wave", "circles"… |
| how that was found: parallel (a word in the variant read off it), vision or assumed |
| where its picture box is, in fractions of the front, for holo and reverse foil |
| how that was found: vision or the standard layout |
| its printed border: foil (it shines, as on Pokémon-ex and LV.X cards) or plain |
| how that was found: vision or assumed |
| inside its foil border, in fractions of the front |
| how that was found: vision or the standard layout |
| its front's surface: textured (raised ridges, embossed in the model from the photo's own lines) or smooth |
| how that was found: vision or assumed |
| a thick card's thickness in points, when given |
| its size of card: standard, small (Yu-Gi-Oh! and Japanese size) or other |
| how that was found: vision or assumed |
| its stock: standard, or thick (a patch, relic or acrylic card) |
| how that was found: vision or assumed |
| its front's finish: glossy or matte |
| how that was found: vision or assumed |
| where its size came from: its format (as the models see it) or given; its thickness: standard, thick, given or pt |
Field | What it holds |
| the words, as lettered |
| the font they were drawn in |
| its license (OFL-1.1) |
| their color |
| where its width and depth came from: given, the default, or round in section |
Field | What it holds |
| who graded it: psa, bgs, cgc, sgc or tag, from its QR code or its label |
| its certification number: from its QR code or barcode, else as read off its label (identifiedBy.cert says which, and whether both agreed) |
| the grader's page for this cert: its QR code's link, else built from the grader and the cert (PSA, CGC, BGS) |
| the holder it was built as (psa, cgc-tall…) |
| the card and the label inside: each one's size, middle and what placed it; the card's corners, foil and its pattern, border and texture; the label's finish (foil or paper) and where its hologram is; and the grader's logo on the insert, where it was found |
| where its size came from: the holder table, or measured |
Field | What it holds |
| its product barcode (UPC or EAN) and its kind, when a photo shows one |
| where each of its sizes came from: measured, photos (its proportions there, scaled by a measured size or the estimate), or the vision models' estimate |
| how rounded its corners and edges are: sharp, slight, round or very |
| how that was found: vision or assumed |
| its surface: glossy or matte |
| how that was found: vision or assumed |
Name the profile, or leave it out and thicken picks one:
An ISBN barcode on any picture, or --isbn, means a book.
A QR code pointing at a grader's site (psacard.com, beckett.com,
cgccards.com, gosgc.com, taggrading.com) means a slab, and says whose.
The sidecar keeps the grader, the cert number from the link, and the link
itself (verifyUrl).
So does an older label's Code 128 cert barcode, but only on a photo shaped like a holder. The grader is then the one the vision models read off the label; with no vision, a PSA-size holder is assumed, with a warning.
Artwork with transparency around a shape that isn't just a rectangle means a badge.
Otherwise, with vision, the models are shown the
profiles and say which it is, and roughly how big: two agreeing settle it,
as with faces, and box takes anything box-shaped the others don't cover.
Anything still unknown is refused with a request to name the profile. Other barcodes don't count: books carry UPCs, QR codes and library stickers.
The sidecar's identifiedBy.profile says which way it was chosen: given,
recognized (codes or the artwork), or vision.
Adding a profile is one file in src/profiles, found by itself, nothing
else to change: its name; a few words on what it is and on each of its faces,
which is all the vision models are told; what to read off it (more is better:
the sidecar is for apps to take what they want from); optionally how its codes
or pictures give it away unaided; and how to build it from the photos placed
on its faces. Generic profiles are named for the shape they build (box, and
later perhaps flat or cylinder), not "unknown": a shape thicken can't
build is refused rather than forced into one it can. Contributions welcome:
CONTRIBUTING.md says how.
Pictures are placed on faces by what they show (see Photos). With no front, Open Library's cover stands in, marked for review, so one photo of the back is enough to start a book.
With THICKEN_VISION_URL set, the photos
themselves (re-encoded, so without their EXIF) go to that host. A LAN server
you control still forwards each photo to the model's provider; a hosted
endpoint sees every photo. With THICKEN_BENCH_URL naming a
Benchwarmers gateway with a vision
collection, the photos go to that gateway, which forwards each to the
providers of every seat it picks. The only other calls out are a book's catalog
lookups (Open Library, the Library of Congress, Google Books), which send its
ISBN, or the title and author the models read off it; never a photo.
Nothing else is sent anywhere, and nothing is fetched at run time but those lookups: previews draw with model-viewer served from your own disk.
A profile is one file, found by itself: what the object is, its faces, what to read off it, and how to build it. Make your own while you use thicken, or improve one of its own, and offer it back:
thicken profile new vinyl # from the template, in ~/.thicken/profiles: used at once
thicken profile check vinyl # what thicken's CI will check
thicken profile contribute vinyl # forks, branches, checks and opens the pull requestThe template, templates/profile.ts, works as it is (a box at the size you give) and says on every field what goes there, the records it writes included. CONTRIBUTING.md has the rest. The table above is made from the profiles themselves.
Report a vulnerability privately, as SECURITY.md says. It also lists what thicken touches: files, the network, and the programs it runs.
Part | How | Choice |
Triangulating badge outlines | Dependency | mapbox/earcut (ISC) |
Writing GLB | Dependency | |
Decoding HEIC | Dependency | catdad-experiments/libheif-js (LGPL-3.0, used unmodified). sharp's binaries leave out HEVC. |
Reading barcodes | Dependency | Sec-ant/zxing-wasm (MIT). Its |
Pictures from scanner PDFs | Dependency | unjs/unpdf (MIT, pdf.js inside) |
Frames from video | Outside program | FFmpeg, run from the |
Reading camera details (EXIF) | Dependency | devongovett/exif-reader (MIT): parses the EXIF block sharp returns |
Drawing previews | Dependency | google/model-viewer (Apache-2.0): frames and lights a GLB; three.js inside |
Running the preview browser | Dependency | microsoft/playwright ( |
MCP server | Dependency | modelcontextprotocol/typescript-sdk (MIT), the official SDK, with colinhacks/zod (MIT) for its tools' inputs |
Book dimension sources | Write | Read palmerabollo/node-isbn's provider fallback. Ours is per dimension, not first-provider-wins. The Library of Congress's one field (MARC 300) is read with a regular expression, not a MARC library. |
Hardcovers | Write | Four rounded boxes from |
Holofoil | Write | Which areas shine for each kind of foil read from simeydotme/pokemon-cards-css (GPL-3.0: facts read, nothing copied); the film values are |
Profiles, box, classifier, CLI | Write | |
Slab holder, card and label | Write | glTF-Transform's materials (already a dependency) for the clear holder; the card and label plates, where they sit, and putting them together are ours. Khronos's glTF-Sample-Assets were the reference for clear materials. |
Finding faces in photos | Write | Vision models over any OpenAI-compatible endpoint, primary and peer (src/vision.ts): one POST each, no SDK. |
Straightening faces | Adapt, don't depend | jlouthan/perspective-transform (MIT): the 4-point homography; the resampling over sharp's pixels is ours. sharp has no perspective warp, and OpenCV.js is megabytes for one. |
Snapping corners to edges | Write |
|
Lettering's font | Dependency | opentypejs/opentype.js (MIT) reads it: the words' outlines, kerned. The font is Titan One by Rodrigo Fuenzalida, shipped unmodified under the SIL Open Font License 1.1 ( |
Inflating letters | Adapt, don't depend | Each pixel's distance from the outline is mapbox/tiny-sdf's (BSD-2-Clause) exact distance transform, ported; it places the outline to a fraction of a pixel. The rise is ours: √u, where ∇²u = −2 inside the letters, round in section across any stroke. |
For refractor and holo effects in a viewer, simeydotme/pokemon-cards-css is
a reference only. It is GPL-3.0, so read it and don't copy it.
TypeScript on Node 22.18+, with sharp for images. From a clone it runs
directly (Node strips the types). The npm package is JavaScript built into
dist (npm run build, run by npm pack and npm publish), because Node
won't strip types inside node_modules. Every push installs the packed
package on Windows, macOS and Linux and runs it.
From a clone: npm install, then node src/cli.ts … in place of
thicken …; npm test, npm run check, and npm run readme after
changing a profile.
MIT. See LICENSE.
The lettering font, Titan One, is under the SIL Open Font License 1.1 (fonts/OFL.txt).
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.
| Name | Required | Description | Default |
|---|---|---|---|
| pt | No | A thick trading card's thickness in points (thousandths of an inch: 55, 75, 100, 130, 180) | |
| out | No | Where to write the GLB (an absolute path ending in .glb); the sidecar goes beside it as .json, never over a .json that isn't a thicken sidecar. Default: beside the first picture, named after it | |
| isbn | No | A book's ISBN, 10 or 13 digits: its size and catalog record are looked up | |
| holder | No | A graded slab's holder: psa, psa-thick, psa-tall, bgs, cgc, cgc-tall, sgc or tag | |
| inputs | No | Absolute paths of the photos (JPEG, PNG, HEIC, WebP, AVIF, GIF, TIFF, SVG), scanner PDFs or videos (MOV, MP4) of one object, in any order and named anything. For the lettering profile, the words instead. Empty with an isbn: a book from its ISBN alone | |
| corners | No | Faces a person placed: {"<photo file name>": {"<face>": [[x,y],[x,y],[x,y],[x,y]]}}, corners top-left first, clockwise, in the photo's own pixels. They take the place of the models' | |
| cropped | No | Each photo is cropped to the object's edges: the vision models say which face it shows, not where. Use it when the user cropped them, or when the review says the models disagreed where a face is | |
| preview | No | Also draw <name>.preview.png, both sides of the model (needs Chrome or Edge installed) | |
| profile | No | The kind of object, if known; else thicken works it out from a code on it (an ISBN barcode, a grader's QR code) or the vision models. thicken_profiles lists them | |
| size_mm | No | The object's real size in millimeters, any part of it, where measured: it outranks every lookup and estimate | |
| depth_mm | No | A badge's or lettering's thickness in millimeters | |
| width_mm | No | A badge's or lettering's width in millimeters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the load and does well: it discloses that two files are written, what they contain, that paths and main facts are returned, and that behavior shifts based on THICKEN_VISION_URL/THICKEN_VISION_MODELS. It leaves failure modes (model disagreement, non-thicken .json collision behavior) to the schema rather than surface text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, and nearly every sentence carries a distinct operational fact (env gate, cropping rule, single-object rule). The middle clause about vision models and public catalogs is dense and slightly convoluted, costing a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter, nested-object, no-annotation, no-output-schema tool, the description covers purpose, file side effects, return shape in brief, and the profile-discovery sibling. What is missing is how errors or low-confidence vision results surface, though the schema's 'review' reference hints at it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter rules the schema does not state: empty inputs is meaningful when an ISBN is supplied, and the profile only has to be named in the no-vision-roster case. It does not characterize how size_mm, pt, and depth_mm interact beyond the schema's own note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with unusual precision: photos of one object become a GLB at real size in millimeters plus a JSON sidecar of catalog/vision metadata. It also separates itself from the only sibling by assigning profile enumeration to thicken_profiles, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete invocation conditions: uncropped photos only when a vision roster is configured, otherwise straight-on cropped photos plus an explicit profile; and 'one object a call: for several, call once each.' It names thicken_profiles as the lookup for profiles but does not state a case where thicken_make itself is the wrong choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe, non-mutating listing, so the bar is lower. The description adds the field-level content of each profile but says nothing about ordering, size, or whether the list is exhaustive or paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence listing profile contents, followed by one sentence of usage, with the purpose front-loaded. Slightly dense in the first clause but no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining what comes back, and it does describe the profile fields an agent will receive. Ordering/pagination details are absent but not critical for a small static catalog.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters and the schema coverage is 100%, so there is nothing for the description to disambiguate. The baseline for a zero-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists thicken's profiles') and enumerates what each profile records: what it is made from, what it makes, and what vision models read off it. The reader can immediately distinguish it from the sibling thicken_make, which is named directly in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two concrete call conditions: to select a profile for thicken_make, or to tell the user what thicken can make. The alternative tool is named explicitly, so the agent knows exactly what this listing feeds into.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.1thicken_make2 fields changedInput schema / properties / cornersAdded value: +{
+ "additionalProperties": {
+ "additionalProperties": {
+ "items": {
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+ },
+ "maxItems": 4,
+ "minItems": 4,
+ "type": "array"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "description": "Faces a person placed: {\"<photo file name>\": {\"<face>\": [[x,y],[x,y],[x,y],[x,y]]}}, corners top-left first, clockwise, in the photo's own pixels. They take the place of the models'",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Input schema / properties / croppedAdded value: +{
+ "description": "Each photo is cropped to the object's edges: the vision models say which face it shows, not where. Use it when the user cropped them, or when the review says the models disagreed where a face is",
+ "type": "boolean"
+}thicken_makethicken_profilesScored 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.
Turn product photos into true-scale 3D models and AR pages, then publish, embed and catalog them.
Free text/image → 3D: generate, rig, avatar-ify, and refine GLB models. No auth, no payment.
3D avatar/asset foundry: text/image -> rigged, validated, engine-ready GLB via x402.
Turn text or an image into an animation-ready 3D model (GLB): generate, rig, animate, retexture.