Which integrations are available for this server?

Enables AI assistants to execute terminal commands and perform file system operations on Linux environments with configurable security constraints and directory whitelisting. Enables AI assistants to execute terminal commands and perform file system operations on macOS environments with configurable security constraints and directory whitelisting.

How do I use cmd-line-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., "@cmd-line-mcp list the files in the current directory" 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.

cmd-line-mcp

by wwqdrh

Overview Schema Related Servers Score Discussions

Python

Local

cmd-line-mcp

npm version License: MIT Node.js

A secure Model Context Protocol (MCP) server that allows AI assistants to execute terminal commands with controlled directory access and command permissions.

Written in JavaScript (ESM) — works with npx out of the box, no Python runtime required.

Quick Start

Run with npx (no install)

npx cmd-line-mcp
npx cmd-line-mcp --config /path/to/config.json
npx cmd-line-mcp --config config.json --env .env

Global install

npm install -g cmd-line-mcp
cmd-line-mcp

Local install

npm install cmd-line-mcp
npx cmd-line-mcp

Claude Desktop Integration

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "cmd-line": {
      "command": "npx",
      "args": ["-y", "cmd-line-mcp"],
      "env": {
        "CMD_LINE_MCP_SECURITY_REQUIRE_SESSION_ID": "false",
        "CMD_LINE_MCP_SECURITY_AUTO_APPROVE_DIRECTORIES_IN_DESKTOP_MODE": "true"
      }
    }
  }
}

Or with a custom config file:

{
  "mcpServers": {
    "cmd-line": {
      "command": "npx",
      "args": ["-y", "cmd-line-mcp", "--config", "/path/to/config.json"]
    }
  }
}

Restart Claude for Desktop after saving.

Configuration

Configuration is resolved in this order (later overrides earlier):

Built-in default_config.json
File pointed to by CMD_LINE_MCP_CONFIG environment variable
--config <path> CLI argument
.env file (searched from cwd upward)
CMD_LINE_MCP_* environment variables

Example `config.json`

{
  "security": {
    "whitelisted_directories": ["/home", "/tmp", "~/Projects"],
    "auto_approve_directories_in_desktop_mode": false,
    "require_session_id": false,
    "allow_command_separators": true
  },
  "commands": {
    "read": ["ls", "cat", "grep"],
    "write": ["touch", "mkdir", "rm"],
    "system": ["ps", "ping"]
  }
}

Environment Variable Format

CMD_LINE_MCP_<SECTION>_<SETTING>

Examples:

export CMD_LINE_MCP_SECURITY_WHITELISTED_DIRECTORIES="/projects,/var/data"
export CMD_LINE_MCP_SECURITY_AUTO_APPROVE_DIRECTORIES_IN_DESKTOP_MODE=true
export CMD_LINE_MCP_COMMANDS_READ="awk,jq,wc"

Available MCP Tools

Tool	Description
`execute_command`	Execute any allowed command (read/write/system)
`execute_read_command`	Execute read-only commands only
`approve_directory`	Grant access to a directory for a session
`approve_command_type`	Grant permission for a command category
`list_directories`	List whitelisted and approved directories
`list_available_commands`	Show commands grouped by category
`get_command_help`	Get usage guidance and examples
`get_configuration`	View current server configuration

Supported Commands (default)

Read (no approval needed)

ls, pwd, cat, less, head, tail, grep, find, which, du, df, file, uname, hostname, uptime, date, whoami, id, env, history, sort, wc, ...

Write (approval required)

cp, mv, rm, mkdir, rmdir, touch, chmod, chown, ln, echo, tar, gzip, zip, unzip, awk, sed, ...

System (approval required)

ps, top, htop, who, netstat, ifconfig, ping, ssh, curl, wget, xargs, ...

Blocked (always denied)

sudo, su, bash, sh, zsh, eval, exec, dd, mkfs, shutdown, reboot, ...

Security Architecture

┌───────────────────────────────────────────────────────────────┐
│                   COMMAND-LINE MCP SERVER                     │
├──────────────────┬────────────────────────┬───────────────────┤
│ COMMAND SECURITY │   DIRECTORY SECURITY   │ SESSION SECURITY  │
├──────────────────┼────────────────────────┼───────────────────┤
│ ✓ Read commands  │ ✓ Directory whitelist  │ ✓ Session IDs     │
│ ✓ Write commands │ ✓ Runtime approvals    │ ✓ Persistent      │
│ ✓ System commands│ ✓ Path validation      │   permissions     │
│ ✓ Blocked list   │ ✓ Home dir expansion   │ ✓ Auto timeouts   │
│ ✓ Pattern filters│ ✓ Subdirectory check   │ ✓ Desktop mode    │
└──────────────────┴────────────────────────┴───────────────────┘

Requirements

Node.js >= 18
macOS or Linux

License

MIT

Original Python source

The original Python implementation is preserved in the temp/ directory for reference.

Available Tools

8 tools

approve_command_typeC

Approve a command type for the current session.

ParametersJSON Schema

Name	Required	Description
`command_type`	Yes	The command type to approve (read, write, system)
`session_id`	Yes	The session ID
`remember`	No	Whether to remember this approval

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 the full burden of behavioral disclosure. It mentions scope ('current session') but fails to explain whether approval is reversible, what permissions it grants, side effects, or persistence behavior beyond the 'remember' parameter hint.

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 single sentence is front-loaded and contains no wasted words. However, given the lack of annotations and security-sensitive nature of the tool, the extreme brevity leaves critical gaps that could be considered under-sizing rather than admirable conciseness.

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?

Despite 100% schema coverage, the description is insufficient for a permission-control tool with no output schema or annotations. It omits the approval workflow, relationship to execution tools, and security implications that an agent would need to select this tool correctly.

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%, documenting all three parameters including the enum-like values for 'command_type' (read, write, system). The description adds no additional parameter context, meeting the baseline expectation when the schema is self-documenting.

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 states a specific verb ('Approve') and resource ('command type') and scopes it to the 'current session'. It distinguishes from sibling 'approve_directory' by referencing 'command_type' rather than directories. However, it omits what 'approval' means functionally or why it's needed.

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, or when approval is required. Given siblings like 'execute_command' and 'execute_read_command', the description should clarify that approval is a prerequisite for execution, but it does not.

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

approve_directoryC

Approve access to a directory for the current session.

ParametersJSON Schema

Name	Required	Description
`directory`	Yes	The directory to approve access to
`session_id`	Yes	The session ID
`remember`	No	Whether to remember this approval

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 but discloses minimal behavioral traits. It mentions 'current session' implying temporariness, but fails to explain what 'access' entails (read/write/execute), side effects, persistence mechanics of the 'remember' parameter, or failure modes.

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 single sentence is efficiently structured with the action verb front-loaded. While appropriately brief, it errs on the side of under-specification given the lack of annotations and security-sensitive nature of the operation.

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 permission/approval tool with no annotations and no output schema, the description is inadequate. It lacks critical security context, does not explain what capability the approval grants, omits interaction patterns with sibling execution tools, and provides no error handling or return value information.

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%, establishing a baseline of 3. The description adds minimal semantic value beyond the schema, though 'for the current session' provides slight context for the session_id parameter. No additional constraints, formats, or examples are 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?

The description clearly states the verb (approve), resource (directory), and scope (current session). However, it does not explicitly distinguish from sibling tool 'approve_command_type', leaving implicit differentiation through the resource type mentioned.

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?

The description provides no guidance on when to use this tool versus alternatives, prerequisites for invocation, or when approval is necessary. It does not clarify the relationship to 'execute_command' or if directory approval is required before command execution.

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

execute_commandC

Execute a Unix/macOS terminal command.

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	The command to execute
`session_id`	No	Optional session ID for permission management

TDQS

C2.8/5.0

Behavior2/5

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 but only specifies the target platform (Unix/macOS). It omits critical information: whether execution is sandboxed, destructive capabilities, error handling behavior, or that the session_id parameter relates to permission management (though the schema covers this).

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

Conciseness3/5

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

The single-sentence description is efficiently structured with no redundancy, but for a high-risk tool capable of arbitrary system modification, this brevity represents under-specification rather than effective conciseness.

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 high complexity and risk of arbitrary command execution, combined with absent annotations and no output schema, the description is dangerously incomplete. It lacks safety warnings, return value documentation, and clarification of destructive capabilities that are essential for agent decision-making.

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 both 'command' and 'session_id' adequately documented in the input schema. The tool description adds no additional parameter context, meeting the baseline expectation when the schema is comprehensive.

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 verb ('Execute') and resource ('Unix/macOS terminal command'), providing specific platform context. However, it fails to distinguish from sibling tool 'execute_read_command', leaving ambiguity about whether this tool performs write operations or general execution.

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 provided on when to use this tool versus 'execute_read_command' or other siblings. Given the high-risk nature of arbitrary command execution, the absence of prerequisites, safety warnings, or selection criteria is a significant gap.

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

execute_read_commandA

Execute a read-only Unix/macOS terminal command (ls, cat, grep, etc.).

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	The read-only command to execute
`session_id`	No	Optional session ID for permission management

TDQS

A4/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 the full burden. It discloses the 'read-only' constraint (critical for safety), but lacks details on enforcement (what happens if 'rm' is passed?), output format, exit codes, timeout behavior, or sandbox boundaries expected for shell execution tools.

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 with efficient parenthetical examples. No wasted words. However, given the high-stakes nature of shell execution, it is slightly too terse—one additional sentence on safety or output would improve utility without bloating.

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?

For a tool executing arbitrary shell commands, the description is minimally adequate. With no output schema and no annotations, it should disclose behavioral specifics like error handling, return structure, or command validation rules. Currently relies entirely on the 'read-only' keyword for safety signaling.

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 coverage is 100%, establishing a baseline of 3. The description adds value by providing concrete examples (ls, cat, grep) that clarify the expected syntax and nature of the 'command' parameter beyond the schema's generic description.

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?

Specific verb 'Execute' + resource 'Unix/macOS terminal command' with clear scope restriction 'read-only'. The parenthetical examples (ls, cat, grep) concrete the intent. Effectively distinguishes from sibling 'execute_command' by emphasizing the read-only constraint.

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 'read-only' descriptor provides clear context for when to use this tool (inspection/reading) versus when to avoid it (modification/writing). However, it does not explicitly name the sibling alternative 'execute_command' for non-read operations.

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

get_command_helpB

Get detailed help about command capabilities and usage.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/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 the full burden. It states the tool retrieves 'help' but discloses nothing about the return format, whether this operation is safe/destructive, or if it requires pre-approval given the existence of 'approve_command_type' and 'approve_directory' siblings.

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, efficient sentence with no redundant words. However, given the lack of annotations and output schema, it may be overly terse rather than appropriately concise.

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?

While the tool has zero parameters (low complexity), the absence of annotations and output schema creates an information gap. The description should explain the return structure or clarify this tool's role in the command execution/approval workflow suggested by sibling tools like 'approve_command_type' and 'execute_command'.

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 input schema has zero parameters, establishing a baseline score of 4. The description correctly implies no filtering parameters are needed to retrieve help, which aligns with the empty schema.

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 uses a clear verb ('Get') and specifies the resource ('detailed help about command capabilities and usage'). It implies this provides documentation depth beyond what 'list_available_commands' (a sibling) would offer, though it doesn't explicitly contrast with siblings.

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?

The description provides no guidance on when to use this tool versus siblings like 'list_available_commands' (which likely just lists names) or 'execute_command'. It doesn't indicate whether this should be used before execution, for troubleshooting, or for discovering parameters.

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

get_configurationC

Get the current configuration settings.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.8/5.0

Behavior2/5

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, yet it fails to mention what format the configuration is returned in, whether it contains sensitive data, or any caching behavior.

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 single sentence is efficiently structured and front-loaded, containing no wasted words, though the overall description is under-specified rather than excessively verbose.

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 absence of an output schema and annotations, the description should indicate what configuration scope is returned (e.g., server settings, command paths, approved directories). As it stands, the agent cannot predict what data structure or content to expect.

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 accepts zero parameters, meeting the baseline score of 4 for this dimension as no additional parameter semantics are required beyond the empty 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 basic action (Get) and resource (configuration settings), but does not specify what system or component's configuration is being retrieved, nor does it differentiate from sibling information-retrieval tools like get_command_help or list_available_commands.

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, or what prerequisites might exist for accessing configuration data.

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

list_available_commandsB

List all available commands by category.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/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 disclosure burden. While 'List' implies a read-only operation, the description fails to specify the output format, what constitutes a 'category,' whether the listing is static or dynamic, or if there are rate limiting concerns. It mentions 'by category' but does not explain the categorization scheme.

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 exactly six words with zero redundancy. It is front-loaded with the action and object, contains no filler words, and every term conveys necessary information about the operation's scope and organization.

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 low complexity (zero parameters) and lack of annotations, the description meets minimum viability by stating the core function. However, without an output schema, it should ideally describe what data is returned (command names, descriptions, categories) to help the agent parse results.

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 input schema contains zero parameters. Per the scoring guidelines, zero parameters establishes a baseline score of 4. The description correctly omits parameter discussion since none exist, and the 100% schema description coverage is trivially satisfied.

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 uses a specific verb ('List') and resource ('available commands') and includes the organization method ('by category'). It distinguishes clearly from siblings like execute_command (execution vs. listing) and list_directories (commands vs. directories), though it could explicitly differentiate from get_command_help.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not clarify when to use this discovery tool versus get_command_help for detailed documentation, nor does it mention prerequisites like requiring authentication or specific permissions to view available commands.

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

list_directoriesC

List all whitelisted and approved directories.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	No	Optional session ID to get session-specific approvals

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 the full burden of behavioral disclosure but fails to state whether this is a read-only operation, what data structure is returned, or how 'whitelisted' differs from 'approved'. It omits security implications and error conditions.

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 single-sentence description is extremely compact (6 words) with no wasted language. However, it borders on underspecification given the security context and optional parameter; additional context would improve utility without sacrificing clarity.

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?

For a tool with one optional parameter and no output schema, the description meets minimum viability by identifying the core resource. However, given the security context (whitelisting/approvals), it lacks necessary context about the approval workflow and session-scoping behavior.

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?

The input schema has 100% description coverage for the 'session_id' parameter, establishing the baseline. The description adds no parameter-specific context, but given the complete schema coverage, this is acceptable. The description neither repeats nor contradicts the schema documentation.

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 uses a specific verb ('List') and clear resource ('whitelisted and approved directories'), establishing the tool's function effectively. It implicitly connects to the sibling tool 'approve_directory' by referencing the approval concept, though it doesn't explicitly differentiate from 'list_available_commands'.

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 siblings like 'approve_directory', or when to utilize the optional 'session_id' parameter. The description lacks prerequisites, exclusions, or contextual advice for the security-sensitive domain of directory whitelisting.

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.

8 tool updatesv0.5.1Mar 27, 2026
- First observedapprove_command_type
- First observedapprove_directory
- First observedexecute_command
- First observedexecute_read_command
- First observedget_command_help
- First observedget_configuration
- First observedlist_available_commands
- First observedlist_directories

Install Server

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

TDQS

B3.4/5.0

Disambiguation4/5

Most tools have distinct purposes, but there is some potential overlap between 'execute_command' and 'execute_read_command' as both execute commands, which could cause confusion about when to use each. The other tools are clearly differentiated by their specific functions like approval, listing, and configuration.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern throughout, such as 'approve_command_type', 'execute_command', and 'list_directories'. However, there is a minor deviation with 'get_command_help' and 'get_configuration' using 'get' instead of a more action-oriented verb, but overall the pattern is predictable and readable.

Tool Count5/5

With 8 tools, the count is well-scoped for a command-line MCP server, covering key operations like execution, approval, listing, and configuration without being overwhelming. Each tool appears to serve a necessary function in managing and executing commands.

Completeness4/5

The toolset provides good coverage for command-line operations, including execution, approval, listing, and help. A minor gap is the lack of tools for updating or deleting configurations or approvals, but agents can likely work around this with the existing tools for most workflows.

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Remote MCP A
com.remote-mcp.mcp
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Developer Tools Search Agent Orchestration
13
secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
Raziel A
io.github.tide-foundation
MCP server teaching AI agents to implement TideCloak: auth, E2EE, IGA, security analysis
Security Autonomous Agents
202

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/wwqdrh/MCPcmd'

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

cmd-line-mcp

Quick Start

Run with npx (no install)

Global install

Local install

Claude Desktop Integration

Configuration

Example config.json

Environment Variable Format

Available MCP Tools

Supported Commands (default)

Read (no approval needed)

Write (approval required)

System (approval required)

Blocked (always denied)

Security Architecture

Requirements

License

Original Python source

Available Tools

Tool Schema Changelog

Resources

Looking for Admin?

Related MCP Connectors

Latest Blog Posts

MCP directory API

Example `config.json`