Skip to main content
Glama

generate_bookmark

Create a custom 3D-printable bookmark with optional front-face decoration, page clip, size, material, and color settings, then preview it in an interactive orbit/zoom 3D stage.

Instructions

Generate a bookmark with optional decoration and page clip. Opens Kiln's interactive inline 3D stage on the result (orbit/zoom panel in MCP Apps hosts; hosted sessions add a browser stage link). 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.

INLINE 3D STAGE: on success this tool opens Kiln's interactive 3D stage — an inline viewer panel the user can orbit, zoom, and turn over — in hosts that render MCP Apps panels (Kiln's hosted connection attaches a browser stage link for hosts that don't). Oversized meshes are decimated automatically for the stage; the PNG preview is the floor, not the whole experience.

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

Input Schema

NameRequiredDescriptionDefault
sizeNoSize preset — ``"slim"``, ``"standard"``, ``"wide"``. Any other name is refused. Default: "".
brief_idNoOptional saved-goal id from ``design_session``. When supplied, the produced mesh gets a ``design_brief:<id>`` intent sidecar so the audit's "matches what you asked for" gate, the brief failure_history wiring, and the ``compare_design_versions`` intent diff all light up against the saved goal. Omit to skip — REST callers without a goal still get an auto-inferred brief at dispatch time. Default: "".
materialNoMaterial (default PLA). Default: "PLA".
width_mmNoWidth in mm (default 30). Default: 30.0.
length_mmNoLength in mm (default 120). Default: 120.0.
body_colorNoBody color (default white). Default: "white".
decorationNoFront-face content -- ``"text:..."``, SVG path, or empty. Default: "".
corner_styleNoTop shape -- ``"rounded"``, ``"pointed"``, or ``"flat"``. Default: "rounded".
include_stepNoAlso emit a CAD-exact STEP file. The STEP is REAL analytic B-rep built from the same typed parameters as the mesh — true planes and cylinders a machine shop's CAD opens clean, never a tessellated conversion. On success the response gains a ``step`` block with ``step_path``. SVG-decorated bookmarks export too — the logo rides along as exact vector contours, the same outlines the mesh carves — and the mesh outputs are always unaffected. Default: false.
thickness_mmNoThickness in mm (default 1.2, range 0.8--2.0). Default: 1.2.
clip_depth_mmNoPage clip depth (default 15mm, 0 = no clip). Default: 15.0.
color_overridesNoJSON dict mapping role → color name/hex. Overrides body_color for "body" role unless body_color is also set. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv1.5.1
    • changedInput schema / properties / body_color / description
      Previous value: -"Default: \"white\"."New value: +"Body color (default white). Default: \"white\"."
    • changedInput schema / properties / brief_id / description
      Previous value: -"Default: \"\"."New value: +"Optional saved-goal id from ``design_session``. When supplied, the produced mesh gets a ``design_brief:<id>`` intent sidecar so the audit's \"matches what you asked for\" gate, the brief failure_history wiring, and the ``compare_design_versions`` intent diff all light up against the saved goal.  Omit to skip — REST callers without a goal still get an auto-inferred brief at dispatch time. Default: \"\"."
    • changedInput schema / properties / clip_depth_mm / description
      Previous value: -"Default: 15.0."New value: +"Page clip depth (default 15mm, 0 = no clip). Default: 15.0."
    • changedInput schema / properties / color_overrides / description
      Previous value: -"Default: \"\"."New value: +"JSON dict mapping role → color name/hex. Overrides body_color for \"body\" role unless body_color is also set. Default: \"\"."
    • changedInput schema / properties / corner_style / description
      Previous value: -"Default: \"rounded\"."New value: +"Top shape -- ``\"rounded\"``, ``\"pointed\"``, or ``\"flat\"``. Default: \"rounded\"."
    • changedInput schema / properties / decoration / description
      Previous value: -"Default: \"\"."New value: +"Front-face content -- ``\"text:...\"``, SVG path, or empty. Default: \"\"."
    • changedInput schema / properties / include_step / description
      Previous value: -"Default: false."New value: +"Also emit a CAD-exact STEP file.  The STEP is REAL analytic B-rep built from the same typed parameters as the mesh — true planes and cylinders a machine shop's CAD opens clean, never a tessellated conversion.  On success the response gains a ``step`` block with ``step_path``.  SVG-decorated bookmarks export too — the logo rides along as exact vector contours, the same outlines the mesh carves — and the mesh outputs are always unaffected. Default: false."
    • changedInput schema / properties / length_mm / description
      Previous value: -"Default: 120.0."New value: +"Length in mm (default 120). Default: 120.0."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PLA\"."New value: +"Material (default PLA). Default: \"PLA\"."
    • changedInput schema / properties / size / description
      Previous value: -"Default: \"\"."New value: +"Size preset — ``\"slim\"``, ``\"standard\"``, ``\"wide\"``. Any other name is refused. Default: \"\"."
    • changedInput schema / properties / thickness_mm / description
      Previous value: -"Default: 1.2."New value: +"Thickness in mm (default 1.2, range 0.8--2.0). Default: 1.2."
    • changedInput schema / properties / width_mm / description
      Previous value: -"Default: 30.0."New value: +"Width in mm (default 30). Default: 30.0."
  2. Addedv1.5.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description goes further by disclosing that a successful call opens an interactive inline 3D stage, that hosts without MCP Apps panels get a browser stage link instead, that oversized meshes are automatically decimated, and that the PNG preview is the minimum deliverable. That is meaningful behavior beyond the annotation surface, though it never says where artifacts are written or what a failure looks like.

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

Conciseness2/5

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

The 3D-stage behavior is stated twice — once in the opening paragraph and again verbatim in the 'INLINE 3D STAGE' section — which is pure redundancy. The 'MAKE DOORS' section is largely meta-commentary about Kiln installation topology that displaces more useful per-tool guidance, and the whole thing is longer than a single-purpose generator warrants.

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?

With 12 optional parameters, full schema coverage, and no output schema, the description carries the burden of explaining returns — and it does describe the stage panel, the PNG preview, and the hosted-session link, plus the step-file behavior via the schema. The main remaining gap is where generated artifacts land and what error conditions look like, but for a generator with a rich schema this is close to complete.

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 all 12 parameters including size presets, thickness range, and clip depth semantics. The description adds only the high-level framing of 'optional decoration and page clip' and does not elaborate on any parameter beyond the schema, so the baseline 3 applies.

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 first sentence states a specific verb and resource ('Generate a bookmark') plus its two main feature axes (optional decoration, page clip), which is enough to distinguish it from the many mesh/analysis siblings. It also explicitly names design_session and compile_scad as different things, though it never contrasts itself with the near-identical generate_* product tools (generate_keychain, generate_nameplate, generate_coaster).

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

Usage Guidelines3/5

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

The 'MAKE DOORS' paragraph gives real routing context (design_session is not installed; compile_scad is the make→preview→iterate loop), which is implied guidance about where this tool sits. However, there is no explicit statement of when to pick generate_bookmark over compile_scad or over the other generate_* product tools, and no prerequisites or exclusions.

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