Syntope Engine
Syntope Engine is a headless engine for design tokens on the open DTCG standard. It is a library, not a running service: the package @syntope/token-core in the folder packages/engine. Every surface has the same engine built in, from the same repository.
What it does
- Validates documents against the official DTCG 2025.10 Format and Resolver schemas.
- Resolves references, reports cycles and missing targets, and builds the dependency graph.
- Composes themes through Resolver sets and modifiers.
- Reads DTCG Format documents, Resolver projects and project packages. Tokens Studio exports are read through an adapter package,
@syntope/import-tokens-studio. - Writes the complete project as one JSON file or as a package of files.
- Protects changes. Each edit builds one complete candidate project and validates it first. If that fails, nothing changes. A delete or rename that would break a reference is refused and names the dependent tokens. A delete can be forced on request, a rename cannot.
- Keeps stable IDs, so renaming a token or moving a set does not create a new object.
- Plans Figma changes as plain data: which value goes on which layer property, and which variables a sync needs. Syntope Tokens, the Figma plugin, carries the plan out.
All 13 token types of DTCG Format 2025.10 are supported, plus a Syntope string type, stored so that files stay valid. See DTCG extensions.
What it deliberately does not do
It calls no Figma API and no browser API. The engine’s build starts with a check, check:dom-globals, that reads every production source file and fails on Figma typings, the figma global, browser-only globals, and imports the package does not declare.
It does no input or output of its own. The package declares two dependencies, colorjs.io and css-tree, so Node’s file system and network modules are out of reach too. You pass files in as strings and get strings back. Reading files, storing projects and talking to Git belong to whatever embeds the engine.
It has no user interface and no storage of its own. Every operation takes a project and returns a new one.
How the surfaces use it
| Surface | What the engine does there | What the surface adds |
|---|---|---|
| Syntope Tokens (Figma plugin) | Validation, resolution, every token and set operation, import and export. The Figma side only receives resolved values. | Figma layer and variable access, storage in the Figma file, transport to Git |
| Syntope MCP (Mac app) | Validates the project it receives from the plugin and selects the tokens it returns. | The connection to AI apps. Changes are sent to the plugin and go through the engine there. |
| Your own tools | Whatever you import from its two entry points. | Everything else |
| Syntope CLI | Planned | Not built yet |
Syntope Bridge is the local connection between the plugin and the Mac app. The engine is not behind it.
A second build check, check:boundaries, keeps these layers apart. It fails if an app imports another app, or reaches into a package through anything but that package’s exports.
Next steps
- Use the engine in code: build it, install it, resolve your first token
- DTCG extensions: what Syntope stores beyond the standard