Skip to main content
Glama
Sign In
sketchflow-mcp

sketchflow-mcp

by 4Ship-ca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

model_build

Build or modify a 3D model by applying a batch of operations atomically, with per-operation results and an optional four-view preview.

Instructions

Build or change the 3D model with a batch of operations (atomic: all apply or none, one undo step for the user). Same operations the UI uses. Returns per-op results (new ids, edge convexity) and the model summary; look:true also returns a picture of the 4 views. See the server instructions for the op list, connector names and mate rules.

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": {
      "ops": "<ops>"
    },
    "name": "model_build"
  }
}

Input Schema

NameRequiredDescriptionDefault
fitNozoom the user's views to fit afterwards (default true)
opsYesOperations, applied in order. Each is an object with "op": add | set | mate | unmate | boolean | separate | edge | weld | pattern | extrude | loft | revolve | sweep | delete | origin | ground | fix | cleanup | dim | setdim | dimaxis | undim | var | link | unlink | joint | drive | suppress | rollback | move | duplicate | rename | material | addon | callout.
lookNoalso return a PNG of the views after building (default false)
labelNoUndo-history label the user sees, e.g. "Add mounting holes"
layoutNowith look: which view(s) to picture
relativeNopositions (at, near) are measured from the model origin, like model_describe reports them (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0-beta.1

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses atomicity ("all apply or none"), undo semantics ("one undo step for the user"), return payload (per-op results with new ids and edge convexity, plus model summary), and the side effect of look:true producing a four-view image. It omits failure modes, permissions, and what happens to existing user selection/views beyond the fit flag.

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?

Four dense sentences, front-loaded with the action and atomicity, then returns, then the pointer to server instructions. Every sentence carries information; the delegation to server instructions is efficient rather than evasive, though it slightly defers what could be inline.

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 very large surface (49 op codes, six parameters, no output schema), the description covers atomicity, undo, return shape and the optional image, and sensibly delegates the op catalogue to server instructions. The main residual gap is that the return payload and per-op result fields are only sketchily characterized and no output schema exists to fill that in.

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 coverage is 100%, so the schema already defines fit, look, layout, label, relative and the nested op object, making 3 the baseline. The description adds only modest value: it clarifies ordering ("applied in order") and ties look to a picture of the four views, but it does not explain the per-op fields other than by reference to server instructions.

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?

States a specific verb and resource ("Build or change the 3D model") plus the unit of work ("a batch of operations"), and adds that these are "the same operations the UI uses," which orients the agent immediately. It does not explicitly distinguish itself from siblings like model_view or model_import, leaving the boundary to inference.

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?

Usage is implied rather than stated: it is a write tool for building/changing geometry in batch, and the pointer to server instructions suggests where op semantics live. There is no explicit when-to-use versus alternatives (e.g. model_view for viewing, model_describe for reading), nor when-not-to-use or prerequisites.

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