Provides tools for cloning Git repositories and executing terminal commands for Git operations
Enables creation of new Next.js projects with configurable TypeScript support and automatic dependency installation
Allows creation of new React projects using Vite with various template options including TypeScript and SWC variants
Provides tools for creating Vue and React projects using Vite with template selection and dependency management
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., "@MCP Terminal & Git Server create a new React project called my-app on my desktop"
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.
MCP server for git and terminal access
This MCP server provides the following tools:
execute_command: Execute a terminal command in a specified directory.
git_clone: Clone a git repository to a specified location.
install_react_project: Create a new React project using Vite.
install_vue_project: Create a new Vue project using Vite.
install_next_project: Create a new Next.js project.
open_in_vscode: Open a directory or file in VSCode.
check_directory: Check if a directory exists and list its contents.
Related MCP server: Project Creator MCP
Node.js (which includes npm)
Visual Studio Code (for features that open projects in VSCode)
Clone the repository (if you haven't already):
git clone https://github.com/AbdurRaahimm/mcp-git-terminal-server.git mcp-terminal
cd mcp-terminalInstall dependencies:
npm installBuild the server:
npm run buildStart the server:
npm run startAlternatively, you can use the development script which builds and then starts the server:
npm run devThe server will then be running on stdio, ready to accept MCP requests from a compatible client.
To configure this server with an MCP client, you might need to specify the path to the built index.js file (e.g., dist/index.js in this project's root) and the command to run it (e.g., node). Refer to your MCP client's documentation for specific instructions.
Here's a more detailed look at the available tools and their parameters:
execute_commandExecute a terminal command in a specified directory.
Input Schema:
command (string, required): The command to execute (e.g., 'npm install', 'ls -la').
cwd (string, optional): Working directory for the command (defaults to current directory).
git_cloneClone a git repository to a specified location.
Input Schema:
repositoryUrl (string, required): Git repository URL.
destination (string, required): Destination path where to clone the repository.
openInVSCode (boolean, optional): Open the cloned repository in VSCode (default: false).
install_react_projectCreate a new React project using Vite and open it in VSCode.
Input Schema:
projectName (string, required): Name of the React project.
destination (string, required): Directory where to create the project (e.g., ~/Desktop).
template (string, optional, enum: ["react", "react-ts", "react-swc", "react-swc-ts"]): Vite template to use (default: react-ts).
installDependencies (boolean, optional): Install dependencies after creating project (default: true).
install_vue_projectCreate a new Vue project using Vite and open it in VSCode.
Input Schema:
projectName (string, required): Name of the Vue project.
destination (string, required): Directory where to create the project (e.g., ~/Desktop).
template (string, optional, enum: ["vue", "vue-ts"]): Vite template to use (default: vue-ts).
installDependencies (boolean, optional): Install dependencies after creating project (default: true).
install_next_projectCreate a new Next.js project and open it in VSCode.
Input Schema:
projectName (string, required): Name of the Next.js project.
destination (string, required): Directory where to create the project (e.g., ~/Desktop).
typescript (boolean, optional): Use TypeScript (default: true).
installDependencies (boolean, optional): Install dependencies after creating project (default: true).
open_in_vscodeOpen a directory or file in VSCode.
Input Schema:
path (string, required): Path to open in VSCode.
check_directoryCheck if a directory exists and list its contents.
Input Schema:
path (string, required): Directory path to check.
This project is licensed under the MIT License. (As specified in package.json)
{
"mcpServers": {
"git-terminal": {
"command": "node",
"args": ["/path/to/mcp-git-terminal/dist/index.js"]
}
}
}Check if a directory exists and list its contents
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path to check |
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 mentions checking existence and listing contents, but lacks details on permissions needed, error handling (e.g., if path doesn't exist), output format, or rate limits. This is a significant gap for a tool that interacts with the filesystem.
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 front-loads the core functionality ('Check if a directory exists and list its contents'). There is zero waste, and every word earns its place by clearly stating the tool's purpose without 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 filesystem interaction tool. It doesn't explain what the return values are (e.g., boolean existence plus array of contents), error conditions, or behavioral traits like whether it recursively lists subdirectories. This leaves gaps for an AI agent to use it correctly.
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 schema description coverage is 100%, with the parameter 'path' clearly documented as 'Directory path to check'. The description adds no additional meaning beyond this, such as path format examples or constraints. With high schema coverage, the baseline score of 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 tool's purpose with specific verbs ('check if exists' and 'list contents') and resource ('directory'). It distinguishes from siblings like 'execute_command' or 'git_clone' by focusing on directory inspection rather than execution or project setup. However, it doesn't explicitly differentiate from potential similar tools (none present in siblings).
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., path must be accessible), exclusions (e.g., not for file checking), or comparisons to sibling tools like 'open_in_vscode' for directory navigation. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a terminal command in a specified directory
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to execute (e.g., 'npm install', 'ls -la') | |
| cwd | No | Working directory for the command (defaults to 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 but doesn't mention risks (e.g., destructive commands, security implications), permissions required, or output handling (e.g., stdout/stderr capture). For a command execution tool with zero annotation coverage, this is a significant gap in safety and operational context.
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 front-loads the core action ('Execute a terminal command') and adds necessary context ('in a specified directory'). There is zero waste, making it easy for an agent to parse quickly without extraneous 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 the complexity of command execution (potential for destructive actions, security risks) and lack of annotations or output schema, the description is incomplete. It doesn't address behavioral traits like error handling, command safety, or output format, leaving critical gaps for safe and effective tool use by an AI agent.
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 clear descriptions for both parameters: 'command' (e.g., 'npm install') and 'cwd' (working directory with default). The description adds minimal value beyond the schema, only implying directory context without detailing parameter interactions or constraints. Baseline 3 is appropriate as the schema handles most documentation.
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 ('execute') and resource ('terminal command'), specifying it occurs 'in a specified directory'. It distinguishes from siblings like 'check_directory' or 'git_clone' by focusing on command execution rather than directory inspection or Git operations. However, it doesn't explicitly differentiate from installation tools, leaving some ambiguity.
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 like 'install_next_project' or 'open_in_vscode'. It lacks context about prerequisites, such as needing a terminal environment, or exclusions, like avoiding dangerous commands. Without such guidance, the agent must infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clone a git repository to a specified location
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | Yes | Git repository URL | |
| destination | Yes | Destination path where to clone the repository | |
| openInVSCode | No | Open the cloned repository in VSCode (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions cloning but lacks details on behavioral traits: it doesn't specify if it overwrites existing directories, requires authentication for private repos, handles errors, or has rate limits. The description is minimal and misses critical operational context 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.
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. Every word contributes to understanding the tool's purpose without 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 the complexity of a git cloning operation (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It fails to address key aspects like error handling, success indicators, or integration with sibling tools (e.g., 'open_in_vscode' for the optional parameter). More detail is needed for safe and effective use.
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 three parameters. The description adds no additional meaning beyond implying a cloning action with a destination. It doesn't explain parameter interactions or provide examples, but the high schema coverage justifies the baseline score of 3.
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 ('Clone') and resource ('a git repository'), specifying the destination ('to a specified location'). It distinguishes from siblings like 'open_in_vscode' by focusing on cloning rather than opening. However, it doesn't explicitly differentiate from other installation tools (e.g., 'install_next_project'), which might be related but serve different purposes.
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., git installation), when not to use it (e.g., for existing repositories), or compare it to sibling tools like 'execute_command' for similar tasks. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Next.js project and open it in VSCode
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Name of the Next.js project | |
| destination | Yes | Directory where to create the project (e.g., ~/Desktop) | |
| typescript | No | Use TypeScript (default: true) | |
| installDependencies | No | Install dependencies after creating project (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, it doesn't specify what happens if the directory exists, what permissions are needed, whether it modifies system state, or what happens on failure. The description lacks critical behavioral context for a tool that creates files and opens applications.
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 front-loads the core functionality. Every word earns its place - 'Create' (action), 'new Next.js project' (what), 'and open it in VSCode' (additional outcome). No wasted words or redundant information.
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?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation (success/failure indicators), what 'open in VSCode' means practically, or system requirements. The combination of mutation behavior and lack of structured metadata demands more descriptive 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?
With 100% schema description coverage, the input schema already documents all 4 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain parameter relationships, constraints, or usage patterns. The baseline score of 3 reflects adequate but minimal value addition.
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 specific action ('Create a new Next.js project and open it in VSCode'), including both the creation and opening steps. It distinguishes from siblings like install_react_project and install_vue_project by specifying Next.js, and from open_in_vscode by including project creation.
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 implies usage for creating Next.js projects, but provides no explicit guidance on when to use this versus alternatives like install_react_project or install_vue_project. There's no mention of prerequisites, when-not scenarios, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new React project using Vite and open it in VSCode
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Name of the React project | |
| destination | Yes | Directory where to create the project (e.g., ~/Desktop) | |
| template | No | Vite template to use | |
| installDependencies | No | Install dependencies after creating project (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions creating and opening a project but lacks details on behavioral traits such as whether it overwrites existing directories, requires specific permissions, handles errors, or has side effects like installing dependencies (implied but not explicit).
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 front-loads the core action and includes key details (Vite, VSCode) without unnecessary words. Every part earns its place.
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 project creation tool with no annotations and no output schema, the description is incomplete. It lacks information on success/failure outcomes, error handling, and behavioral details needed for safe and effective use, leaving significant 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 baseline is 3. The description does not add meaning beyond the schema, as it does not explain parameter interactions, defaults, or usage examples (e.g., how destination interacts with projectName).
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 specific action ('Create a new React project') with the technology stack ('using Vite') and the subsequent action ('open it in VSCode'). It distinguishes from siblings like install_next_project and install_vue_project by specifying React and Vite.
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 does not mention prerequisites, compare with siblings like install_next_project or git_clone, or indicate when not to use it (e.g., for existing projects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Vue project using Vite and open it in VSCode
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Name of the Vue project | |
| destination | Yes | Directory where to create the project (e.g., ~/Desktop) | |
| template | No | Vite template to use | |
| installDependencies | No | Install dependencies after creating project (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions creating a project and opening it in VSCode, but does not disclose behavioral traits such as whether it overwrites existing directories, requires specific permissions, handles errors, or has side effects like modifying system files. For a mutation tool with zero annotation coverage, this 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 front-loads the core action ('Create a new Vue project') and includes key details (using Vite, opening in VSCode) without unnecessary words. Every part of the sentence earns its place.
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 tool's complexity (creating and opening a project), no annotations, and no output schema, the description is minimally adequate but lacks completeness. It covers the what but not the how or what happens next (e.g., success/failure indicators, project structure). For a tool with 4 parameters and mutation behavior, more context would be helpful.
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 all parameters thoroughly. The description does not add any meaning beyond what the schema provides, such as explaining parameter interactions or default behaviors. Baseline 3 is appropriate when 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 specific action ('Create a new Vue project using Vite and open it in VSCode'), including the technology stack (Vue, Vite) and the post-creation action (open in VSCode). It distinguishes from sibling tools like install_react_project and install_next_project by specifying Vue, and from open_in_vscode by including project creation.
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 implies usage for Vue project creation with Vite, but does not explicitly state when to use this tool versus alternatives like install_react_project or git_clone. It provides context (creating Vue projects) but lacks explicit exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a directory or file in VSCode
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to open in VSCode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose if this requires VSCode installation, what happens if the path doesn't exist, whether it opens in a new window or existing instance, or any error handling, which are critical for a tool that interacts with external applications.
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, direct sentence with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration, earning full marks for clarity and brevity.
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 opening files in an external editor and the lack of annotations and output schema, the description is insufficient. It doesn't cover behavioral aspects like prerequisites, error cases, or what success looks like, leaving significant gaps for the agent to operate this tool effectively in real-world scenarios.
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, clearly documenting the 'path' parameter. The description adds no additional semantic information beyond what the schema provides, such as path format examples or constraints, so it meets the baseline for high schema coverage without enhancing parameter understanding.
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 ('Open') and target ('a directory or file in VSCode'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'check_directory' or 'execute_command', which might also involve file system operations, so it misses the highest clarity level.
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. For example, it doesn't specify if this is for opening existing files vs. creating new ones, or how it differs from 'check_directory' or other sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes: check_directory for inspection, execute_command for general terminal operations, git_clone for repository cloning, and three project installation tools for different frameworks. However, the three install_*_project tools could potentially be confused as they follow similar patterns but target different frameworks, creating minor ambiguity in selection.
The naming shows mixed conventions: check_directory, execute_command, and git_clone follow a verb_noun pattern, while install_next_project, install_react_project, and install_vue_project use a verb_framework_project structure. open_in_vscode uses a prepositional phrase. This inconsistency makes the set less predictable, though still readable.
With 7 tools, the count is reasonable for a combined terminal and Git server. It covers core operations like directory checking, command execution, Git cloning, project setup, and IDE opening. The scope is slightly broad but manageable, with no obvious bloat or thinness.
The server covers basic terminal and Git operations, but there are notable gaps. For terminal operations, it lacks file manipulation (create, delete, edit) and navigation tools. For Git, it only includes cloning, missing commit, push, pull, and status operations. The project installation tools are framework-specific but don't cover other common setups.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Manage repositories, users, releases, and automate GitHub workflows
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AbdurRaahimm/mcp-git-terminal-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
