OCCTMCP Tool Reference

A detailed, per-tool reference for the OCCTMCP MCP surface — one page per tool family, every tool documented: what it does, its JSON-Schema parameters, what it returns, a runnable example call with an example response, the underlying OCCTSwift / occtkit it drives, and gotchas.

OCCTMCP is an MCP server, not a library: clients call these tools over stdio MCP, each with a single JSON-object argument, and get JSON text back. The Swift server (occtmcp-server) is the canonical 59-tool surface documented here; the Node server exposes a 37-tool subset — each tool notes its Node availability.

This complements the other docs:

• Cookbook — task-oriented recipes that chain these tools.
• README tool table — the one-line catalog.

Page layout

One file docs/reference/<family>.md per tool family. Each page:

---
title: <Family>
parent: Tool Reference
nav_order: <n>
---

# <Family>

<1–3 sentences: what this family is for and when an LLM reaches for it.>

## Tools

- [`tool_a`](#tool_a) · [`tool_b`](#tool_b) · …

---

## `tool_name`     ← one `##` per tool, in the page's tool order

<one-line summary — what it does.>

**Server:** Swift + Node   *(or)*   Swift only

**Parameters**

| name | type | required | description |
|------|------|:--------:|-------------|
| `bodyId` | string | yes | … |
| `metrics` | string[] | no | … |

<omit the row's table entirely if the tool takes no arguments; say "No parameters.">

**Returns** — <what the JSON result contains; note error conditions.>

**Example**

​```json
// tool call arguments
{ "bodyId": "part", "metrics": ["volume", "boundingBoxOptimal"] }
​```
​```json
// example result
{ "volume": 1000.0, "boundingBoxOptimal": { "min": [0,0,0], "max": [10,10,10] } }
​```

**Notes** — gotchas / cross-references. *(omit if none)*
**Drives** — the OCCTSwift call / occtkit verb behind it. *(omit if unknown)*

Entry rules (the contract)

1. Parameters come verbatim from the JSON Schema provided to you (docs-build/schemas/<family>.json) — names, types, required, and the schema description. Do not invent or rename parameters.
2. Every tool in the family file gets one ## section, in the order listed in that file.
3. Server: line is required — use the nodeAvailable flag in the schema: Swift + Node when true, Swift only when false.
4. Examples must be schema-faithful — only real parameters, correct types. Keep them minimal and realistic (a bodyId like "part", a path under the output dir). Mark illustrative result JSON as an example; don’t over-specify exact numbers you can’t know.
5. No invention. Behaviour comes from the schema description, the README, and the architecture notes in your prompt. If a detail is unclear, state it briefly — don’t fabricate.
6. Concise. Reference, not prose: one summary line, a parameter table, returns, one example.

Families

Table of contents

• Core & scripting
• Scene mutation
• Introspection & measurement
• Construction
• Engineering analysis
• Selection & remap
• Annotations & overlays
• I/O
• Mesh & visualization
• Topology graph
• Reconstruction graph