Skip to content

[tracking] DSL/IR authoring tools for the OCCTStudio consumer #37

Description

@gsdali

Context

OCCTMCP exposes 57 typed CAD tools + execute_script (arbitrary Swift). The downstream OCCTStudio app (private/commercial, built on this ecosystem) authors models in a portable declarative DSL that lowers to a canonical feature-graph IR (the same family as this repo's / OCCTSwiftScripts' reconstruct). For OCCTStudio's in-app AI loop to round-trip with the user's script + GUI, the MCP layer needs to read and write the DSL/IR, not only author Swift via execute_script.

Proposed direction (to be finalized once the IR schema is locked)

  • IR-level tools likely belong here (OSS-compatible). The IR ≈ the feature-graph that reconstruct/FeatureReconstructor already consumes, which is open-source. Candidate tools: emit IR (feature-graph JSON), patch IR, and read back the current scene as IR.
  • DSL emission likely stays app-side. The DSL surface syntax is OCCTStudio's (commercial); an OCCTStudio-side adapter renders IR ⇄ DSL. This keeps the OSS boundary clean — no part of OCCTMCP may depend on the closed OCCTStudio app.
  • Decide the IR-tools-here vs adapter-only split when the IR is locked.

Status — BLOCKED

This is a tracking issue. Concrete tool specs depend on OCCTStudio's DSL/IR being finalized; several IR args field names still need reconciling against FeatureReconstructor's decoder. Flesh this out (or close in favour of an app-side adapter) once the IR schema is locked.

Refs: OCCTStudio docs/DSL_DESIGN.md, docs/knowledge/architecture/ai-architecture.md.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions