Skip to main content
Glama
enesjakozh
PhialsBasement

cmd-mcp-server

by PhialsBasement
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

CMD MCP 서버

대장간 배지npm 다운로드 Windows와 Linux 모두에서 CMD 명령을 실행하고 SSH 연결을 허용하는 모델 컨텍스트 프로토콜(MCP) 서버 구현입니다. 이 서버를 사용하면 명령줄 작업을 MCP 호환 애플리케이션과 통합할 수 있습니다.

특징

  • MCP를 통해 CMD 명령 실행

  • TypeScript 구현

  • 공식 MCP SDK 기반으로 구축됨

  • 크로스 플랫폼 호환성

Related MCP server: Globalping

설치

Smithery를 통해 설치

Smithery를 통해 Claude Desktop용 CMD 서버를 자동으로 설치하려면:

지엑스피1

수동 설치

npm install server-cmd

필수 조건

  • Node.js(v16 이상 권장)

  • npm 또는 yarn 패키지 관리자

용법

import { MCPCmdServer } from 'server-cmd';

// Initialize the server
const server = new MCPCmdServer();

// Start the server
server.start();

구성

서버는 환경 변수나 구성 객체를 통해 구성될 수 있습니다.

const config = {
  // Add your configuration options here
};

const server = new MCPCmdServer(config);

개발

개발 환경을 설정하려면:

  1. 저장소를 복제합니다.

git clone https://github.com/PhialsBasement/CMD-MCP-Server.git
cd CMD-MCP-Server

  1. 종속성 설치:

npm install

  1. 프로젝트를 빌드하세요:

npm run build

스크립트

  • npm run build - TypeScript를 JavaScript로 컴파일

  • npm run prepare - 패키지 게시 준비

종속성

  • @modelcontextprotocol/sdk : ^1.0.1

  • glob : ^10.3.10

  • zod-to-json-schema : ^3.23.5

기여하다

기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

보안

명령줄 작업을 실행하는 것은 잠재적으로 위험할 수 있습니다. 프로덕션 환경에서 이 서버를 사용할 때는 적절한 보안 조치를 구현하고 입력 유효성 검사를 수행해야 합니다.

지원하다

문제 및 기능 요청은 GitHub 문제 추적기를 이용해 주세요.

Available Tools

2 tools
execute_commandA

Execute a command and return its output. Commands run in a persistent shell session by default. Use newSession: true to run in a new shell instance.

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYes
newSessionNo

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that commands run in a persistent shell session by default and can be run in a new instance, which is useful behavioral context. However, it lacks details on permissions, security implications, error handling, or output format, which are important for a command execution 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?

The description is appropriately sized and front-loaded, with two clear sentences that efficiently convey key information without waste. Each sentence earns its place by explaining the core function and a critical parameter behavior.

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?

Given the tool's complexity (command execution with potential security and behavioral implications), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It covers the basic operation and session behavior but lacks details on permissions, error handling, output structure, or safety warnings, which are crucial for such a tool.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining the 'newSession' parameter's effect (running in a new shell instance vs. default persistent session) and implies 'command' is the input to execute. It doesn't detail the 'command' parameter's format or constraints, but provides enough context for basic usage.

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?

The description clearly states the tool's purpose with a specific verb ('Execute') and resource ('a command'), and specifies it returns output. However, it doesn't explicitly differentiate from the sibling 'execute_ssh_command' tool, which likely has a different context or target.

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 provides clear context about when to use the 'newSession' parameter (to run in a new shell instance vs. the default persistent session). It doesn't explicitly mention when to use this tool versus the sibling 'execute_ssh_command' or other alternatives, which is a minor gap.

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

execute_ssh_commandC

Execute a command on a remote server via SSH. Commands run in a persistent SSH session by default. Use newSession: true to run in a new session.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes
portNo
usernameYes
passwordNo
privateKeyNo
commandYes
newSessionNo

TDQS

C2.9/5.0
Behavior2/5

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. It mentions the persistent session behavior and newSession option, which is helpful. However, it doesn't cover critical aspects like security implications, error handling, timeout behavior, or output format. For a tool that executes remote commands with authentication parameters, 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.

Conciseness4/5

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

The description is appropriately concise with two sentences. The first sentence states the core purpose, and the second provides important behavioral context about session persistence. No wasted words, though it could be more comprehensive given the tool's complexity.

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?

For a tool with 7 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain authentication methods (password vs. privateKey), command execution context, error scenarios, or return values. The description should provide more guidance given the tool's security-sensitive nature and complexity.

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 0%, so the description must compensate for all 7 parameters. The description only mentions the 'newSession' parameter explicitly. It doesn't explain the purpose or relationships of host, port, username, password, privateKey, or command parameters. The description adds minimal value beyond what the bare schema provides.

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?

The description clearly states the tool's purpose: 'Execute a command on a remote server via SSH.' It specifies the action (execute), resource (remote server), and method (SSH). However, it doesn't explicitly differentiate from the sibling tool 'execute_command' (which might be for local execution or different protocols).

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 provides some usage context: 'Commands run in a persistent SSH session by default. Use newSession: true to run in a new session.' This gives guidance on session behavior but doesn't explain when to use this tool versus the sibling 'execute_command' or address authentication method selection (password vs. privateKey).

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 updatesv1.0.0
    • Addedexecute_command
    • Addedexecute_ssh_command
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.3/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: execute_command handles local shell commands, while execute_ssh_command handles remote SSH commands. There is no overlap or ambiguity between them, as each targets a different execution environment.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with 'execute_' as the prefix and descriptive suffixes ('command' and 'ssh_command'). The naming is perfectly uniform and predictable across the tool set.

Tool Count2/5

With only 2 tools, the server feels thin for a command execution domain. It lacks essential operations like listing available commands, managing sessions, or handling file operations, which are common in such contexts. The count is too low for adequate coverage.

Completeness2/5

The tool set is severely incomplete for command execution. It covers basic local and remote command execution but misses critical functionalities such as session management tools, command history, file transfer, or environment configuration, leaving significant gaps for agent workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches