Skip to main content
Glama
widgetstools

marketsui-mcp

by widgetstools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

marketsui-mcp

A local Model Context Protocol server that scaffolds new React or Angular apps preloaded with the Markets design system, @widgetstools/dock-manager, AG Grid (themed via DS adapters), and a dark/light theme toggle.

From any MCP-capable client (Claude Desktop, Claude Code, MCP Inspector, …) you can say:

scaffold markets react app at ~/apps/my-demo

and get a ready-to-run project with pinned deps, the full design-system/ tree, and a trading-style dock layout (bond blotter + candlestick chart + order book).

What you get

Each scaffolded app contains:

  • design-system/ — verbatim copy of the Markets DS (themes, adapters, cell renderers), as a sibling of src/.

  • libs/*.tgz — local tarballs for @widgetstools/dock-manager-core, the framework-specific dock manager, and (React) react-day-picker + tabby_ai-hijri-converter. Referenced as file:libs/*.tgz in package.json.

  • Theme toggle — top-right sun/moon button; flips data-theme on <html> and body.dataset.agThemeMode for AG Grid; persisted to localStorage.

  • Dock layout — 3 panels in a DockManagerCore (blotter / chart / order book) using sample data.

  • README with a Design System usage section (CSS imports, @design-system/* path alias, AG Grid + shadcn/PrimeNG adapters, CSS variable reference).

Related MCP server: UI Toolkit MCP Server

Install

Clone and build locally:

git clone <this-repo> marketsui-mcp
cd marketsui-mcp
npm install
npm run build

Optionally link the bin globally:

npm link          # exposes `marketsui-mcp` on PATH

Run

The server speaks MCP over stdio. You normally don't run it by hand — an MCP client launches it. For a quick sanity check:

npx @modelcontextprotocol/inspector node dist/index.js

Then in the inspector UI, invoke scaffold_markets_react_app with:

{ "name": "my-demo", "targetDir": "/tmp/scaffold-test", "runInstall": false }

Register with an MCP client

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent on your platform:

{
  "mcpServers": {
    "marketsui": {
      "command": "node",
      "args": ["/absolute/path/to/marketsui-mcp/dist/index.js"]
    }
  }
}

If you ran npm link, you can use the bin directly:

{
  "mcpServers": {
    "marketsui": { "command": "marketsui-mcp" }
  }
}

Restart Claude Desktop. You should see the scaffold_markets_react_app and scaffold_markets_angular_app tools available.

Claude Code

claude mcp add marketsui -- node /absolute/path/to/marketsui-mcp/dist/index.js

Tools

scaffold_markets_react_app

Field

Type

Default

Description

name

string

—

App name (valid npm package name).

targetDir

string

—

Parent directory; app is created at <targetDir>/<name>. Absolute paths recommended.

runInstall

boolean

false

If true, runs npm install inside the new app.

Returns { path, framework: "react", nextSteps: [...] }.

scaffold_markets_angular_app

Same input shape; produces an Angular 21 + PrimeNG + AG Grid app. Returns { path, framework: "angular", nextSteps: [...] }.

Example session

user: scaffold markets react app called demo at /tmp/scaffold-test

assistant: (calls scaffold_markets_react_app)

→ /tmp/scaffold-test/demo
  cd /tmp/scaffold-test/demo
  npm install
  npm run dev

The dev server boots at http://localhost:5173, shows the dock layout, and the top-right toggle switches between dark and light themes.

Repo layout

marketsui-mcp/
├── src/
│   ├── index.ts              # MCP server entrypoint (stdio)
│   ├── tools/                # scaffold_markets_{react,angular}_app
│   ├── scaffold/             # copyTemplate, copyAssets, postInstall
│   └── util/paths.ts
├── templates/
│   ├── react/                # React + Vite app skeleton
│   │   └── libs/             # pinned .tgz tarballs (full offline tree)
│   └── angular/              # Angular app skeleton
│       └── libs/             # pinned .tgz tarballs (full offline tree)
└── assets/
    └── design-system/        # verbatim DS copy

To refresh pinned versions, re-copy design-system/ and re-run npm pack on the dock-manager packages, then drop the tarballs into templates/{react,angular}/libs/ and regenerate the matching package-lock.json.

Development

npm run dev      # tsc --watch
npm run build    # tsc
npm start        # node dist/index.js

Available Tools

2 tools
scaffold_markets_angular_appC

Scaffold a new Angular app preloaded with the Markets design system, dock manager, AG Grid, PrimeNG, and a dark/light theme toggle. Produces a ready-to-run project at /.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
targetDirYesParent directory where the app will be created. Absolute paths recommended.
runInstallNo

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It states the output location, but says nothing about whether an existing targetDir is overwritten, whether network access is needed, or what runInstall=false implies (the project is 'ready-to-run' yet dependencies may not be installed).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the action and stack, followed by the output artifact. Every clause earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or annotations, so the description must be self-sufficient, and it does communicate the produced artifact and its path. However, it omits overwrite behavior, parameter semantics, and prerequisites for a mutation-style scaffolding tool with 3 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (just targetDir), and the description adds nothing about the undocumented `name` pattern/constraints or `runInstall`. Worse, 'ready-to-run project' arguably conflicts with the runInstall default of false, leaving the agent unclear on installed state.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear specific verb+resource (scaffold an Angular app) with the exact stack enumerated and the output location stated. It differentiates from scaffold_markets_react_app implicitly via the framework name, but never explicitly contrasts the two, so it falls short of the top band.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use/when-not guidance and no prerequisites (Node version, network, existing directory state). The existence of a React sibling means the agent must choose between frameworks, and the description gives no criteria for that choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scaffold_markets_react_appB

Scaffold a new React + Vite app preloaded with the Markets design system, dock manager, AG Grid, and a dark/light theme toggle. Produces a ready-to-run project at /.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
targetDirYesParent directory where the app will be created. Absolute paths recommended.
runInstallNo

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose the output location convention (<targetDir>/<name>) and that the result is ready-to-run. However, it omits critical mutation-side behavior: whether an existing directory is overwritten or an error is raised, and what happens when runInstall is false versus true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the core purpose front-loaded and the output location as a compact follow-up. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description should carry more. It adequately conveys what is generated and where, but leaves undoc'd the runInstall parameter and the failure/overwrite semantics a scaffolding tool needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33% (only targetDir is documented in the schema), so the description must compensate. It does clarify the relationship between the two required params via the <targetDir>/<name> path convention, but it says nothing about runInstall or the name pattern constraint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (scaffold) and resource (React + Vite app) and enumerates the preloaded contents (Markets design system, dock manager, AG Grid, theme toggle). The 'React' framing implicitly distinguishes it from the sibling scaffold_markets_angular_app, though it never names the alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use this versus the Angular sibling, no prerequisites (e.g., target directory must not already exist, Node/Vite availability), and no guidance on the runInstall flag's effect on workflow. The agent must infer selection purely from the framework name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedscaffold_markets_angular_app
    • First observedscaffold_markets_react_app
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly differentiated by framework (React vs Angular), so an agent can easily select the correct one. No overlapping functionality exists between them.

Naming Consistency5/5

Both names follow the exact pattern scaffold_markets_{framework}_app, with consistent snake_case and a predictable verb_noun structure. This makes the naming highly consistent and readable.

Tool Count4/5

Two tools is slightly below the typical 3-15 range, but given the narrow purpose of scaffolding apps for two specific frameworks, each tool earns its place. The count is reasonable but could be seen as thin for a broader design system.

Completeness4/5

The server covers scaffolding for React and Angular, the two main frameworks likely supported by the design system. However, other frameworks (e.g., Vue) or additional scaffold options might be missing, leaving minor gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • UI Toolkit MCP Server

    elsahafy
    A
    license
    A
    quality
    F
    maintenance
    Comprehensive MCP server for end-to-end UI development, offering tools to generate components, manage design tokens, audit accessibility, autofix issues, inspect live pages, compare screenshots, and more across multiple frameworks.
    13
    11 npm
    MIT

  • yourco-mcp

    amitmohapatra
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables developers to build MCP servers with registry-managed tool metadata, runtime hot-reloading, pluggable authentication and authorization, per-audience tool views, and resilient stateless operation.
    -

  • sign-in-form

    krasnoff
    F
    license
    A
    quality
    C
    maintenance
    This MCP server enables MCP Apps-compatible hosts to render an interactive React-based UI and invoke a sample tool over streamable HTTP or stdio transports.
    1
    -