Which integrations are available for this server?

Allows building an Angular UI library and linking it into a consumer application. Enables Git operations such as commit and push via the mhdd24 CLI. Integrates with GitHub for commit and push workflows via the mhdd24 CLI. Facilitates npm linking of the built library into the consumer app.

How do I use workspace-build-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@workspace-build-mcp Build and link core into the app" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

workspace-build-mcp

by Mhdd-24

Overview Schema Related Servers Score Discussions

TypeScript

Local

@mhdd_24/workspace-build-mcp

MCP server and PowerShell scripts to build an Angular UI library and npm-link it into a consumer app. Short aliases (core, app) expand from config. GitHub workflows use the published mhdd24-cli (mhdd24).

Use from Cursor chat or the terminal. Same architecture as Timelog / Flyway / Caffeine / Notepad++ MCP packages.

Full documentation: docs/WIKI.md

How it works (30 seconds)

You (chat or CLI)
  → workspace-build-mcp
  → scripts/workspace-build.ps1
  → ng build + npm link

Git:
  → scripts/workspace-git.ps1 → mhdd24 push | smart-commit

Configure WORKSPACE_ROOT + alias env vars
Say "build and link core" (or run the .ps1)
Use mhdd24 helpers for commit/push when needed

Related MCP server: Build MCP Server

Prerequisites

Requirement	Notes
Node.js 18+	MCP server
Windows	PowerShell scripts
Angular CLI (`ng`)	On PATH
npm	On PATH
mhdd24-cli	`npm i -g mhdd24-cli` for git tools

Install

Option A — npm (after publish)

npm install -g @mhdd_24/workspace-build-mcp

Option B — npx

npx @mhdd_24/workspace-build-mcp

Option C — clone and build

git clone https://github.com/Mhdd-24/Workspace-Build-MCP.git
cd Workspace-Build-MCP
npm install
npm run build
node dist/index.js

Also install the GitHub helper CLI:

npm i -g mhdd24-cli

Configure Cursor

Edit ~/.cursor/mcp.json:

{
  "mcpServers": {
    "workspace-build": {
      "command": "npx",
      "args": ["-y", "@mhdd_24/workspace-build-mcp"],
      "env": {
        "WORKSPACE_ROOT": "C:/path/to/your/workspace",
        "ALIAS_CORE_WS": "FEApp/ClientApp/ui-core-ws",
        "ALIAS_CORE_PROJECT": "ui-core",
        "ALIAS_CORE_DIST": "dist/ui-core",
        "ALIAS_CORE_PACKAGE": "@scope/ui-core",
        "ALIAS_APP_WS": "FEApp/ClientApp/ui-app-ws/ui-app"
      }
    }
  }
}

Local development:

"command": "node",
"args": ["C:/path/to/workspace-build-mcp/dist/index.js"]

Reload MCP after saving.

Environment variables

Variable	Required	Purpose
`WORKSPACE_ROOT`	Yes	Monorepo / workspace root
`ALIAS_CORE_WS`	Yes (for build)	Library workspace (relative to root or absolute)
`ALIAS_CORE_PROJECT`	No	Angular project name (default `ui-core`)
`ALIAS_CORE_DIST`	No	Dist folder under library ws (default `dist/<project>`)
`ALIAS_CORE_PACKAGE`	No	npm package name to link (default `@scope/<project>`)
`ALIAS_APP_WS`	Yes (for link)	Consumer app path
`GIT_CWD`	No	cwd for mhdd24 (defaults to `WORKSPACE_ROOT`)

Aliases: core → library settings; app → consumer app path.

Tools

Tool	Purpose
`ws_status`	Config + `ng` / `npm` / `mhdd24` availability
`ws_list_aliases`	Resolved alias paths
`ws_build_link`	Build library + link into app
`ws_build_only`	Build library only
`ws_git_push`	`mhdd24 push "<message>"`
`ws_git_smart_commit`	`mhdd24 smart-commit`

Chat examples

"List workspace build aliases"
"Build and link core into the app"
"Build core only"
"Push with mhdd24: chore update link"

Terminal

cd path\to\Workspace-Build-MCP
.\scripts\workspace-build.ps1 `
  -LibraryWs "C:\ws\FE\ui-core-ws" `
  -AppWs "C:\ws\FE\ui-app" `
  -NgProject "ui-core" `
  -DistRel "dist\ui-core" `
  -PackageName "@scope/ui-core"

License

ISC

Available Tools

6 tools

ws_build_linkA

Build the UI library (core) and npm-link it into the consumer app. Runs scripts/workspace-build.ps1.

ParametersJSON Schema

Name	Required	Description	Default
`alias`	No	Library alias to build (default: core).
`skipClean`	No	If true, skip deleting dist and Angular caches before build.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool runs a specific script and performs build and link actions, but does not elaborate on side effects (e.g., file modifications, overwrites), authorization needs, or whether it is safe or destructive. The description is minimally adequate but not thorough.

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?

The description is concise with two sentences. The first sentence front-loads the core purpose, and the second provides additional context (script path). No extraneous information.

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

Completeness4/5

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

For a tool with simple parameters and no output schema, the description sufficiently explains the action and the underlying script. It lacks details on prerequisites or expected outcomes, but given the tool's simplicity, it is largely complete.

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?

Both parameters have descriptions in the input schema (100% coverage). The description adds no extra semantics beyond the schema; it mentions 'core' as default alias, which is already documented. With high schema coverage, a baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states that the tool builds the UI library and npm-links it into the consumer app. It uses specific verbs ('Build' and 'npm-link') and resources ('UI library', 'consumer app'). The purpose is distinct from sibling 'ws_build_only', which presumably only builds without linking.

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives like 'ws_build_only'. While the implication is that this tool is for building and linking, there is no guidance on prerequisites, contexts where linking is needed, or when to avoid using it.

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

ws_build_onlyA

Build the UI library only (no npm link into the app).

ParametersJSON Schema

Name	Required	Description	Default
`alias`	No	Library alias to build (default: core).
`skipClean`	No	If true, skip deleting dist and Angular caches before build.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It discloses the core behavior (no linking) but omits details like default clean behavior, side effects, and output.

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?

Single sentence, front-loaded with the core verb and key distinction, no wasted words.

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?

The description covers the core purpose but lacks context on prerequisites, output, and error handling. Given low complexity, it is adequate but not complete.

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 100% with descriptions for both parameters. The description adds no extra parameter info, so baseline of 3 applies.

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

Purpose5/5

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

The description clearly states the action 'Build' and the target 'UI library', with a key distinction 'no npm link into the app' that differentiates it from the sibling tool 'ws_build_link'.

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

Usage Guidelines3/5

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

The description implies usage context (build without linking) but does not explicitly state when to use this tool versus alternatives like ws_build_link.

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

ws_git_pushC

Run mhdd24 push with a commit message in the configured git working directory.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Optional cwd override (defaults to GIT_CWD or WORKSPACE_ROOT).
`message`	Yes	Commit message for mhdd24 push.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. It only mentions that it runs a push command, but does not explain if it commits and pushes, requires a clean working directory, or any destructive actions. This is insufficient for a mutation tool.

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

Conciseness4/5

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

The description is a single concise sentence (15 words) that gets to the point. However, it is too brief, missing important context that would justify more length.

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

Completeness2/5

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

Given no output schema and no annotations, the description is incomplete. It does not mention return values, error behavior, or prerequisites. A tool that pushes code needs more behavioral context for safe use.

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 description coverage is 100%, so baseline is 3. The description adds little beyond the schema: it repeats that message is the commit message and cwd is an override. No additional semantic detail (e.g., format, constraints) is provided.

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?

Description clearly states the action (run mhdd24 push) and the key resource (commit message in configured git working directory). However, it does not differentiate from sibling tool ws_git_smart_commit, which may have overlapping functionality.

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 explicit guidance on when to use this tool versus alternatives like ws_git_smart_commit. The description only states what it does, not when or when not to use it.

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

ws_git_smart_commitC

Run mhdd24 smart-commit in the configured git working directory.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Optional cwd override (defaults to GIT_CWD or WORKSPACE_ROOT).

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are present, so the description must fully disclose behavior. It only says 'Run... smart-commit' without explaining effects (e.g., whether it commits, pushes, or modifies state), permissions needed, or potential risks.

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?

The description is a single concise sentence with no redundant information, achieving maximum efficiency.

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

Completeness2/5

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

Given the single optional parameter and no output schema, the description is too minimal. It does not explain what 'smart-commit' entails or what the tool returns, which is insufficient for a tool with multiple siblings.

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 description coverage is 100% with one parameter 'cwd'. The description adds default values ('GIT_CWD or WORKSPACE_ROOT'), which is helpful, but does not elaborate on format or usage beyond the schema.

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

Purpose3/5

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

The description states the verb 'Run' and the resource 'mhdd24 smart-commit', which indicates what it does. However, 'mhdd24' is ambiguous and the description does not differentiate from sibling tools like 'ws_git_push'.

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 guidance is provided on when to use this tool versus alternatives such as 'ws_git_push' or 'ws_build_only'. The description lacks context for selection.

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

ws_list_aliasesA

List configured aliases (core, app) with resolved absolute paths and package names.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It accurately describes the output (aliases with paths and package names) and implies a read-only operation. No contradictions. Adequate for a simple list tool.

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?

Single sentence, front-loaded with the verb and resource, no wasted words. Perfectly concise for the tool's simplicity.

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

Completeness5/5

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

Given zero parameters, no output schema, and a straightforward purpose, the description covers everything needed. No missing information.

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

Parameters4/5

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

The tool has zero parameters, so baseline is 4 as per scoring rules. The description adds no extra parameter info, but none is needed.

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

Purpose5/5

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

The description clearly states the verb 'list' and the resource 'configured aliases', specifying that it includes 'core, app' types and provides 'resolved absolute paths and package names'. This differentiates it from sibling tools which are build/git/status commands.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. While sibling tools are unrelated, there's no mention of usage context or when not to use it. The description is minimal but adequate given the tool's simplicity.

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

ws_statusA

Check workspace-build configuration: WORKSPACE_ROOT, alias paths, and whether ng/npm/mhdd24 are available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses that the tool checks specific configuration items but does not detail return format, behavior on missing items, or any side effects. For a read-only check, this is adequate but could be more explicit.

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

Conciseness4/5

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

Single sentence is concise and front-loaded. Could be slightly improved by listing items in a structured format, but overall efficient.

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

Completeness4/5

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

For a zero-parameter, no-output-schema tool, the description covers the essentials: what is checked. It does not explain return values, but given the simplicity, it is fairly complete.

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

Parameters4/5

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

No parameters exist, so schema coverage is trivially 100%. The description adds value by specifying what is checked, but with zero params, the baseline of 4 is appropriate.

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

Purpose5/5

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

Description clearly states the tool checks workspace-build configuration, listing specific items (WORKSPACE_ROOT, alias paths, tool availability). This distinguishes it from siblings which perform build, git, or alias listing actions.

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

Usage Guidelines4/5

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

The description implies use for checking configuration status. While no explicit when/not-to-use or alternatives are given, the nature of the tool and sibling names make usage context clear.

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. Dates show when Glama detected each change.

6 tool updatesv1.0.0Jul 8, 2026
- First observedws_build_link
- First observedws_build_only
- First observedws_git_push
- First observedws_git_smart_commit
- First observedws_list_aliases
- First observedws_status

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

All tools have clearly distinct purposes: building with/without linking, two different git operations, listing aliases, and checking status. No overlap between any tool's functionality.

Naming Consistency5/5

All tools follow the consistent `ws_verb_noun` pattern using snake_case, e.g., ws_build_link, ws_git_push, ws_list_aliases. Naming is predictable and readable.

Tool Count5/5

With 6 tools, the server is well-scoped for workspace build management. Each tool serves a distinct and necessary purpose without being overly numerous or sparse.

Completeness4/5

The tool surface covers core workflows: building, git operations, and configuration inspection. Minor gaps exist (e.g., no tool to clean or reset workspace), but the set is sufficient for primary tasks.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

GitResumeOAuth
co.gitresume
Validate, build, and publish the resume you keep as YAML in your own GitHub repository.
Version Control Developer Tools
1
VibeKit A
io.github.VibeKit-Bot
Build, deploy, and operate hosted web apps on VibeKit (vibekit.bot) from any MCP client.
Cloud Platforms Developer Tools
3621
SupernovaOAuth
io.supernova
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Design Tools Documentation Access Developer Tools
1
github
com.mcparmory
Manage repositories, users, releases, and automate GitHub workflows
Version Control CI/CD & DevOps Developer Tools
2

Related MCP Servers

MCP Tool Starter Kit
Developer Tools CI/CD & DevOps
He110te4m
F
license
C
quality
Not graded
maintenance
A feature-complete TypeScript project template for rapidly developing Model Context Protocol tools with integrated best practices for code quality, testing, and automated deployment.
Updated a year ago (2025-07-28 01:11 UTC)
1
-
Build MCP Server
Developer Tools CI/CD & DevOps Code Execution
TeodorTrotea
F
license
B
quality
D
maintenance
Enables AI assistants to manage development workflows by running build commands, executing tests, analyzing package.json files, installing dependencies, and performing code linting. Supports multiple package managers (npm, yarn, pnpm) and provides detailed error reporting for development operations.
Updated a year ago (2025-08-14 07:36 UTC)
5
-
Angular Component Inspector
Developer Tools Code Analysis Documentation Access
marcosviniweb
F
license
Not graded
quality
D
maintenance
Enables dynamic exploration of Angular library components by reading and analyzing the public API exports. Provides tools to list available components and retrieve detailed component information.
Updated 9 months ago (2025-12-04 12:55 UTC)
-
mcp-shipcheck
Developer Tools Testing & QA Tools Code Analysis
mcp-tool-shop-org
A
license
A
quality
A
maintenance
Audits local package folders to generate publish-readiness reports and previews of NPM tarball contents. It helps developers identify and resolve configuration issues like missing types or broken exports before releasing code.
Updated 2 months ago (2026-07-07 21:24 UTC)
3
89
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mhdd-24/Workspace-Build-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server