sketchflow-mcp

Overview Schema Source Related Servers Discussions Admin

model_import

Import STL, OBJ, or STEP files from disk as editable mesh parts for sketching and parametric 3D modeling, with optional scale, material, mates, and booleans.

Instructions

Import an STL (binary or ASCII), OBJ or STEP file from disk as mesh parts (STL / OBJ re-centred on the base, stacked on the ground unless mated later; STEP: each solid kept where it is in the file — STEP files with planar faces only, as SketchFlow writes them and faceted exports from other tools; curved CAD surfaces are refused with the reason). It takes mates, booleans, materials and mass like any part. scale e.g. 25.4 for a model in inches.

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": {
      "path": "<path>"
    },
    "name": "model_import"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes
`scale`	No
`material`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0-beta.1Nov 6, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses placement behavior (STL/OBJ re-centred on the base, stacked on the ground unless mated later; STEP solids kept where they are), an input restriction (planar faces only), and a failure mode (curved CAD surfaces are refused with the reason). It also notes that imported parts participate in mates, booleans, materials, and mass. It stops short of stating whether import overwrites anything, how naming collisions are handled, or whether the operation is reversible.

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?

The core action and format list are front-loaded, and every sentence carries information. The long nested parenthetical about placement and STEP restrictions is dense but not wasteful; it could be split for readability, but no sentence is filler.

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 three-parameter, no-annotation, no-output-schema tool, the description covers purpose, format support, placement side effects, a hard input limitation, and the scale unit. What remains thin is the 'material' parameter and general error/return behavior outside the STEP case.

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 0% across three parameters, so the description must compensate. It explains 'scale' with a concrete example ('25.4 for a model in inches') and implicitly covers 'path' via 'from disk', but 'material' is only gestured at through 'takes ... materials ... like any part' with no format or expected value. Roughly two of three parameters get meaningful semantics.

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 ('Import') and resource ('STL (binary or ASCII), OBJ or STEP file from disk as mesh parts'), and enumerates the accepted formats. It is clearly distinguishable from siblings like open_model or place_image.

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 through the format list and the planar-face constraint on STEP, but there is no explicit when-to-use guidance and no routing away from alternatives such as open_model, model_reference, or place_image. The conditions under which importing is the right choice versus another modeling entry point are left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.