Enables running ESLint code linting and quality checks through the lint_code tool to identify and report code quality issues
Supports running npm commands for building projects, executing tests, installing dependencies, and managing Node.js packages
Enables dependency management using pnpm as an alternative package manager for installing and managing Node.js project dependencies
Provides support for Yarn package manager to install dependencies, run build commands, and execute test suites in development projects
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Build MCP Server run tests in the backend directory with yarn"
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.
A Model Context Protocol (MCP) server that provides build and development tools for AI assistants. This server enables AI agents to run build commands, tests, linting, and manage dependencies in development projects.
Build Management: Run build commands with customizable parameters
Test Execution: Execute test suites and report results
Package Analysis: Read and analyze package.json files
Dependency Management: Install dependencies using npm, yarn, or pnpm
Code Linting: Run linting tools and report code quality issues
Related MCP server: npm-run-mcp-server
npx build-mcp-servergit clone <your-repo-url>
cd build-mcp-server
npm install
npm run buildAdd this server to your MCP configuration file:
{
"mcpServers": {
"build-server": {
"command": "npx",
"args": [
"-y",
"build-mcp-server"
],
"env": {}
}
}
}Or for local development:
{
"mcpServers": {
"build-server": {
"command": "node",
"args": [
"/path/to/build-mcp-server/dist/index.js"
],
"env": {}
}
}
}run_buildExecute build commands in a project directory.
Parameters:
command (string, optional): Build command to run (default: "npm run build")
directory (string, optional): Directory to run the build in (default: current directory)
Example:
Run build command "npm run build" in the current directoryrun_testExecute test suites in a project directory.
Parameters:
command (string, optional): Test command to run (default: "npm test")
directory (string, optional): Directory to run tests in (default: current directory)
Example:
Run tests using "yarn test" in the ./frontend directorycheck_package_jsonAnalyze package.json files and extract key information.
Parameters:
directory (string, optional): Directory containing package.json (default: current directory)
Example:
Check package.json in the current directoryinstall_dependenciesInstall project dependencies using various package managers.
Parameters:
manager (string, optional): Package manager to use - npm, yarn, or pnpm (default: "npm")
directory (string, optional): Directory to install dependencies in (default: current directory)
Example:
Install dependencies using yarn in the ./backend directorylint_codeRun code linting and quality checks.
Parameters:
command (string, optional): Lint command to run (default: "npm run lint")
directory (string, optional): Directory to run linting in (default: current directory)
Example:
Run linting with "eslint ." commandOnce configured, you can use natural language to interact with the build server:
"Build the project"
"Run tests in the frontend directory"
"Install dependencies using yarn"
"Check what scripts are available in package.json"
"Lint the code and show me any issues"
The server provides detailed error messages and output for all operations. Build failures, test errors, and linting issues are clearly reported with full context.
This server executes shell commands in the specified directories. Ensure you trust the environment and commands being executed. The server includes timeout protections to prevent long-running processes.
To contribute or modify the server:
# Clone and install
git clone <repo-url>
cd build-mcp-server
npm install
# Development with auto-reload
npm run dev
# Build for production
npm run build
# Test the server
npm startMIT
Read and analyze package.json file
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | Directory containing package.json (default: current directory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Read and analyze' which implies a read-only operation, but doesn't disclose behavioral traits like what analysis is performed, whether it validates the file, what happens if the file is missing or invalid, or what the output format is. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, front-loading the core action and resource. Every word earns its place, and there's no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that performs analysis. It doesn't explain what analysis is done, what the return values are, or how errors are handled. For a tool with 1 parameter but behavioral complexity implied by 'analyze', this leaves too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'directory' with its type and default. The description adds no additional meaning about parameters beyond what the schema provides, such as path format constraints or analysis options, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read and analyze') and resource ('package.json file'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'lint_code' or 'run_build' which might also interact with package.json files, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over other tools like 'install_dependencies' or 'run_build' that might also read package.json, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install project dependencies
| Name | Required | Description | Default |
|---|---|---|---|
| manager | No | Package manager to use | npm |
| directory | No | Directory to install dependencies in (default: current directory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Install project dependencies' implies a write operation that modifies the project environment, but it doesn't disclose critical traits such as whether it requires network access, has side effects (e.g., modifying node_modules), potential errors (e.g., missing package.json), or output behavior. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded and directly states the tool's purpose without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a dependency installation tool (a mutation operation with potential side effects), the description is incomplete. No annotations or output schema exist to cover behavioral aspects, and the description fails to address critical context like prerequisites, error handling, or what 'install' entails. This leaves significant gaps for an agent to use the tool correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('manager' and 'directory'), including enums and defaults. The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or typical use cases. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Install project dependencies' clearly states the verb ('Install') and resource ('project dependencies'), making the purpose understandable. However, it lacks specificity about what 'install' entails (e.g., installing from package.json) and doesn't distinguish it from sibling tools like 'check_package_json' or 'run_build', which might involve similar contexts. This makes it vague but not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a package.json file), exclusions, or how it relates to siblings like 'run_build' (which might include dependency installation). Without any context for usage, it leaves the agent to infer based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run linting on the codebase
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | Lint command to run (e.g., "npm run lint", "eslint .") | npm run lint |
| directory | No | Directory to run linting in (default: current directory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action ('Run linting') but doesn't explain what happens during execution (e.g., outputs linter warnings, may fail on errors), potential side effects (e.g., modifies files), or performance aspects (e.g., time-consuming). This leaves key behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with parameters. It doesn't cover what the tool returns (e.g., lint results, success/failure status) or behavioral nuances, which are critical for an AI agent to use it effectively. This gap makes it inadequate despite the concise structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameters ('command' and 'directory') with descriptions and defaults. The description adds no additional meaning beyond implying linting occurs, which the schema already covers. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Run') and resource ('linting on the codebase'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'run_build' or 'run_test', which might also involve code analysis, but it's specific enough to convey its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'check_package_json' or 'run_test'. The description lacks context about prerequisites (e.g., dependencies installed) or typical scenarios (e.g., pre-commit checks), leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run build command in the current directory
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | Build command to run (e.g., "npm run build", "yarn build") | npm run build |
| directory | No | Directory to run the build in (default: current directory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe execution behavior (e.g., whether it runs synchronously/asynchronously, error handling, output format, or side effects like file system changes). For a command execution tool, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing build commands (which can have side effects, require specific environments, or produce outputs) and the lack of annotations and output schema, the description is insufficient. It doesn't address behavioral aspects, error conditions, or what the agent should expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema. The description adds no additional parameter semantics beyond implying execution context, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('run build command') and context ('in the current directory'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'run_test' or 'check_package_json', which might also involve command execution in similar contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description doesn't mention prerequisites (e.g., whether dependencies must be installed first), when to choose this over sibling tools like 'run_test', or any exclusions (e.g., not for production builds).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run tests in the current directory
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | Test command to run (e.g., "npm test", "yarn test") | npm test |
| directory | No | Directory to run tests in (default: current directory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Run tests') but doesn't explain what happens during execution (e.g., output format, error handling, side effects like file changes, or performance implications). For a tool that executes commands, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for its purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running tests (which can involve execution, output, and potential side effects), the description is incomplete. With no annotations and no output schema, it fails to explain what the tool returns (e.g., test results, exit codes) or behavioral traits. This leaves critical gaps for an agent to understand the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully documenting both parameters ('command' and 'directory') with examples and defaults. The description doesn't add any meaning beyond this, as it only mentions 'current directory' which is covered by the schema. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run tests in the current directory' clearly states the verb ('Run') and resource ('tests'), but it's vague about what type of tests or framework is involved. It doesn't distinguish from sibling tools like 'check_package_json' or 'run_build', which might also involve testing-related activities. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a test setup), exclusions, or how it differs from siblings like 'lint_code' or 'run_build'. Without such context, an agent might misuse it or overlook better options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
check_package_jsoninstall_dependencieslint_coderun_buildrun_testEach tool has a clearly distinct purpose targeting different aspects of the build process: checking configuration, installing dependencies, linting, building, and testing. There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent verb_noun pattern with snake_case (e.g., check_package_json, install_dependencies). The naming is predictable and readable throughout the set.
With 5 tools, this server is well-scoped for a build automation domain. Each tool earns its place by covering essential build-related tasks without being overly sparse or bloated.
The toolset covers core build workflow steps (check, install, lint, build, test), but lacks operations like cleanup, deployment, or version control integration, which are minor gaps that agents can work around for basic build tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
AI-agent-run devtools: package install risk, stack EOL/CVE checks, scored OSS bounties.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TeodorTrotea/mcptest'
If you have feedback or need assistance with the MCP directory API, please join our Discord server