Docs

Overview MCP Theme Builder Component Builder API Builder Theme config Rule system Builder workflow

Schemyx docs

Codebase context and builder reference

Schemyx MCP is the main bridge into AI coding tools. Codebase context, Theme Builder, and Component Builder create the approved rules it can serve, while API Builder is documented as a roadmap area.

Foundations

Available now

Theme Builder

Turns visual decisions into reusable tokens and component rules that every Schemyx surface can inherit.

UI patterns

Available now

Component Builder

Turns custom component decisions into rules AI can follow when generating product interfaces.

Interface layer

Under construction

API Builder

Planned builder for creating contract-first API context so generated code knows the expected endpoints, schemas, auth, and error states.

Foundations

Available now

Theme Builder

Turns visual decisions into reusable tokens and component rules that every Schemyx surface can inherit.

Inputs

themeConfig.json
brand colors
spacing density
radius scale
surface contrast

Outputs

CSS variables
Tailwind tokens
component sizing
surface states

Guardrails

Preserve background color values unless the theme config changes them.
Map token values before applying one-off component styles.
Keep button, card, badge, and panel treatment consistent across pages.

UI patterns

Available now

Component Builder

Turns custom component decisions into rules AI can follow when generating product interfaces.

Inputs

component inventory
layout patterns
variant rules
interaction states
composition examples

Outputs

component playbook
usage rules
layout recipes
review checklist

Guardrails

Prefer existing components before creating new UI primitives.
Document when to use cards, forms, tables, modals, empty states, and page shells.
Attach visual review criteria so generated screens can be checked against known patterns.

Interface layer

Under construction

API Builder

Planned builder for creating contract-first API context so generated code knows the expected endpoints, schemas, auth, and error states.

This builder is under construction. The details below describe the planned direction and expected documentation structure, not a completed product surface.

Inputs

resource model
endpoint map
auth mode
request schema
response schema

Outputs

API contract
typed payloads
handler rules
integration notes

Guardrails

Define schemas before generating implementation details.
Keep auth, validation, and error behavior explicit.
Document generated contracts where builders and agents can reuse them.

MCP

Use Schemyx codebase context where AI writes code

Schemyx MCP exposes codebase context, Theme Forge, and Component Forge bundles as read-only resources for coding agents. Teams can use hosted project configs for shared, account-backed workflows, or local bundles when they want files committed beside a codebase.

Request Beta Access

Local discovery order

`./schemyx-ui-theme/themeforge.json`
`./schemyx-ui-theme/componentforge.json`
`./.schemyx/theme/themeforge.json`
`./themeforge.json`
Hosted Schemyx API fallback

MCP modes

Hosted config

Save a Theme Forge or Component Forge bundle to a Schemyx project. The local MCP server reads the latest project config from the Schemyx API using an API key.

Local bundle

Download files into `schemyx-ui-theme/` inside a repo. The MCP server finds local Schemyx bundles and serves those files without an API key.

Auto mode

The MCP server checks for local files first, then falls back to hosted Schemyx configs when no local bundle exists.

What it serves

codebase recipes, themeforge.json, componentforge.json, CSS, target-stack files, implementation guidance, and bundle metadata.

What stays read-only

The MCP server reads codebase and UI context. It does not mutate projects or write app code without the coding agent doing that work.

Why local files exist

Local bundles give developers portability, offline use, and a commit-friendly source of truth when they do not want to rely on hosted lookup.

Theme config

Config fields

`themeConfig.json` should stay the source of truth for shared visual behavior. The app maps these values into CSS variables before components consume them.

Current theme fields

fontFamily

Sets the app typeface used by the layout and shadcn-style primitives.

radius

Controls the shared corner radius for cards, panels, and surface framing.

cardPadding

Controls interior spacing for repeated card content.

backgroundColor

Sets the base page color and should stay stable for the current brand direction.

surfaceColor

Sets the card and panel base color.

accentColor

Sets highlight, ring, and subtle motion treatment.

Rule system

Rule structure

A rule should tell a builder what to preserve, what it may change, and how output will be reviewed. Rules should be specific enough to guide generated work.

Scope

Name the builder, surface, or contract the rule applies to.

Constraint

Describe the behavior, token, boundary, or schema that must be followed.

Review

Define what confirms the output stayed inside the rule.

Builder workflow

From input to reusable system context

Builder output should either solve the current task or become reusable context for future work. If it becomes reusable, promote it into the rule system.

Step 1

Collect inputs

Start with the builder inputs: theme values, component rules, or API contract details.

Step 2

Generate context

Normalize those inputs into a reusable config, policy, or contract before building UI or code.

Step 3

Apply guardrails

Check generated output against the builder guardrails before it becomes part of the platform.

Step 4

Promote reusable rules

When a decision repeats, move it into the shared rule system instead of leaving it inside one page.