JsonUI
← Toolsjsonui-mcp-serverForty-four typed tools grouped into six families. The agents use them to inspect any JsonUI project — specs, layouts, components, builds, runtime sync, API model discovery, and test tooling — without each agent needing to re-implement parse, schema-lookup, or file I/O.~12 min read
What MCP isModel Context Protocol is Anthropic's standard for exposing tools to an LLM agent. jsonui-mcp-server is our implementation: it runs as a subprocess that Claude Code (or Codex) spawns on project load, and it publishes a manifest of 45 named tools. Each tool has a typed input schema, a typed output shape, and a brief description. The agent calls them by name; we own the server that answers.
The typed surfaceBecause each tool returns structured data, agents can ask questions like 'what are Collection's attributes?' and get a parseable answer, not prose. The cost of an agent learning a new component is a single call, not a file-tree scan. The cost of reviewing whether the agent used the attribute correctly is one shape-check, not a diff review.
lookup_component (example response)
{
  "tool": "lookup_component",
  "input": { "name": "Collection" },
  "output": {
    "name": "Collection",
    "platforms": ["ios", "android", "web"],
    "attributes": [
      { "name": "items",          "type": ["CollectionDataSource", "binding"], "required": true },
      { "name": "cellIdProperty", "type": "String" },
      { "name": "sections",       "type": "[CollectionSection]" }
    ]
  }
}
Tool catalogHand-authored catalog kept in sync with the MCP server's 6-group tool list (45 tools currently — A:10 / B:7 / C:7 / D:9 / E:3 / F:9). Per-tool parameter docs live at /reference/mcp-tools.
Aget_project_config
Read jui.config.json + platform roots.
Alist_screen_specs
Enumerate every *.spec.json under docs/screens/json/. Since MCP 2.8.0 a parent spec's `subSpecs` are inlined as `screen_sub_spec` rows (name / description / parent), so a split screen's structure is visible without opening the parent file.
Asearch_specs
Keyword-search across ALL spec files — screen specs, sub-specs in subdirectories, component specs — returning file + JSON path + snippet per match. The fast way to find which spec (or which sub-spec of a split screen) covers a topic. Added in MCP 2.8.0.
Alist_layouts
Enumerate every layout JSON under docs/screens/layouts/ with its screen / cell / partial classification (responsive variant files fold under their base entry).
Alist_component_specs
Enumerate every custom component spec under docs/components/json/.
Alookup_component
Return a built-in or custom component's attribute schema.
Alookup_attribute
Return a single attribute's definition (type, enum, default, required) plus, since MCP 2.4.0, the platform truth around it: `platform` (the declared surface), `platform_reasons` (why an excluded platform was excluded, straight from the SSoT), and `implementationGaps` (declared pairs the codegen does not read yet, with their ledger notes).
Asearch_components
Fuzzy search across the component index for exploration. Since MCP 2.8.0, task-phrase queries ("ios only", "platform override" and their Japanese spellings) surface a guide pointer — { guide: "platform_rules", nextTool: "get_platform_rules" } — at the top, so the mechanism is reachable without knowing any attribute name.
Aget_platform_rules
Return the platform-scoping rulebook for layouts: the node-level `platform` object form (merge attributes into one platform only), the string form (drop the node on non-matching platforms; language tokens accepted), the layout-root `platforms` whitelist, precedence (platform override > inline attribute > style value), and how all of this differs from `responsive`. Added in MCP 2.8.0.
Aget_data_source
Report which attribute_definitions.json / component_metadata.json the server loaded — layer, file mtime, and freshness — so agents can confirm the data is current.
Bdoc_validate_spec
Validate a screen_spec.json against the schema.
Bdoc_validate_component
Validate a component_spec.json against the schema.
Bdoc_rules_init
Seed .jsonui-doc-rules.json with the project defaults.
Bdoc_rules_show
Print the active .jsonui-doc-rules.json.
Bjui_verify
Diff on-disk layouts against what the spec would generate (drift gate).
Bget_binding_rules
Return the canonical binding semantics (shared binding_semantics.json) + platform restrictions.
Bget_screen_identity
Return the canonical screen-identity rules (shared screen_identity.json): what counts as a screen, how ids are derived, the runtime marker and the assert:"screen" vocabulary.
Cdoc_init_spec
Create an empty screen_spec.json at the given path with a template shape.
Cdoc_init_component
Create an empty component_spec.json with a template shape.
Cdoc_generate_spec
Emit an HTML doc page for a screen spec. (wraps jsonui-doc CLI — see /tools/doc)
Cdoc_generate_component
Emit an HTML doc page for a component spec. (wraps jsonui-doc CLI — see /tools/doc)
Cdoc_generate_html
Bulk-generate HTML docs across specs — including multi-app whole sites (apps) and extra markdown doc dirs. (wraps jsonui-doc CLI — see /tools/doc)
Cjui_generate_project
Scaffold Layout + ViewModelBase + hook + navigation stubs from a spec.
Cjui_generate_screen
Scaffold a new spec + its initial Layout + VM pair in one step.
Djui_init
Bootstrap a fresh JsonUI project (directories, jui.config.json).
Djui_build
Distribute layouts + styles + strings to every platform and run the per-platform build.
Djui_sync_tool
Pull the latest rjui_tools / sjui_tools / kjui_tools from ~/.jsonui-cli/.
Djui_generate_converter
Scaffold a custom component converter from its spec.
Djui_migrate_layouts
Run the CLI's layout migration sweeps for scheduled breaking changes.
Dread_spec_file
Read a spec file back by path. Used by read-only agents like jsonui-debug.
Dread_layout_file
Read a layout JSON back by path.
Dget_platform_mapping
Return the spec-type → platform-type map (FeaturedLink → SwiftUI struct vs TS interface, etc.).
Dget_modifier_order
Return the canonical modifier order for styling attributes (padding, margin, …).
Elist_api_specs
Discover swagger files in `docs/api/` with title / version / schema_count / endpoint_count metadata, plus any parser halts.
Elist_api_models
Per-platform inventory of generated DTOs, Domain scaffolds, and orphans (the same set `jui ls api-models` reports).
Epreview_api_model_sync
Dry-run filter changes — returns `kept_schemas` / `filtered_out` / `skip_domain_matches` / `halts` as JSON without writing files.
Ftest_validate
Validate screen/flow test files + descriptions against the schema; when `test.install` is configured, installs the validated tests to the platform test dirs.
Ftest_generate_screen
Scaffold a screen test template for a named screen.
Ftest_generate_flow
Scaffold a flow test template spanning multiple screens.
Ftest_generate_description
Scaffold a description JSON for one screen/flow test case.
Ftest_report
Convert results JSON (results.schema.json) into a JUnit XML or HTML report.
Ftest_mock_generate
Scaffold API mock files from OpenAPI into `<mockDir>/generated/`; `check:true` reports drift without writing, comparing scenario bodies against the schema for their status code. (`mock serve` stays CLI-only.)
Ftest_generate_branch_tests
Generate unit-level branch tests from a spec's branchContracts (vitest / Kotlin JUnit4 + Robolectric / Swift XCTest). A screen with no branchContracts is an error, not a no-op.
Ftest_artifacts_pull
Collect run artifacts — iOS xcresult attachments, Android on-device files, and web Playwright videos / screenshots — into the configured artifacts dir; returns absolute paths.
Ftest_artifacts_status
Show the resolved `test.artifacts` config and what has already been collected.
Group semanticsA (Lookup, 8): read-only introspection of specs, layouts, the component index, and the data-source the server itself is using. B (Validation, 6): schema and drift checks — the gate logic agents run before declaring a change done. C (Generation, 7): create the empty shapes the agent will fill in — specs, scaffolds, HTML docs. D (Build + Runtime, 9): orchestrate the per-platform build, sync the tooling, and read files back so read-only agents (jsonui-debug) can work without spawning shell commands. E (API Model Discovery, 3): the 2026-05 group — list_api_specs / list_api_models / preview_api_model_sync — for inspecting and dry-running the swagger → DTO + Domain pipeline. F (Test Tooling, 8): the 2026-07 group — test_validate / test_generate_screen / test_generate_flow / test_generate_description / test_report / test_mock_generate / test_artifacts_pull / test_artifacts_status — for validating, scaffolding, reporting, mocking, and collecting run artifacts (screenshots / recordings) of JsonUI tests (the long-running `mock serve` stays CLI-only). Each group is one conceptual step in the spec-first loop; each tool is one bounded responsibility.
Keep reading
Agents for Claude / CodexThe clients that call these tools — nine agents with named responsibilities./tools/agents
jsonui-cliThe jui orchestrator and per-platform builders that the MCP tools delegate to for heavy lifting./tools/cli