Skip to main content
Glama
Sign In
thicken

thicken

by bikemeardsley
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Make a 3D model with thicken

thicken_make

Converts photos or an ISBN of one object into a real-size GLB model and matching JSON metadata, using vision models and catalog lookups.

Instructions

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.

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": "thicken_make"
  }
}

Input Schema

NameRequiredDescriptionDefault
ptNoA thick trading card's thickness in points (thousandths of an inch: 55, 75, 100, 130, 180)
outNoWhere 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
isbnNoA book's ISBN, 10 or 13 digits: its size and catalog record are looked up
holderNoA graded slab's holder: psa, psa-thick, psa-tall, bgs, cgc, cgc-tall, sgc or tag
inputsNoAbsolute 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
cornersNoFaces 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'
croppedNoEach 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
previewNoAlso draw <name>.preview.png, both sides of the model (needs Chrome or Edge installed)
profileNoThe 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_mmNoThe object's real size in millimeters, any part of it, where measured: it outranks every lookup and estimate
depth_mmNoA badge's or lettering's thickness in millimeters
width_mmNoA badge's or lettering's width in millimeters

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.1
    • addedInput schema / properties / corners
      Added 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"
+}
    • addedInput schema / properties / cropped
      Added 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"
+}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools