cmd-line-mcp

by wwqdrh

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.1
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.
Average 3.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCPcmd MCP server](https://glama.ai/mcp/servers/wwqdrh/MCPcmd/badges/card.svg)](https://glama.ai/mcp/servers/wwqdrh/MCPcmd)

Score Badge

Copy to your README.md:

[![MCPcmd MCP server](https://glama.ai/mcp/servers/wwqdrh/MCPcmd/badges/score.svg)](https://glama.ai/mcp/servers/wwqdrh/MCPcmd)

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