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 CLI Server start a process to ping google.com"
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.
An MCP server that provides tools to interact with CLI applications.
@author: Claudio Alarcon clalarco@gmail.com
uv for execution. Check https://docs.astral.sh/uv/ for installation instructions.
npm (optional) to use the MCP inspector. Check https://docs.npmjs.com/ for installation instructions.
Related MCP server: mcpdeployment
start_process(command: str): Start a new process.
stop_process(pid: str): Stop a running process.
is_alive(pid: str): Check if a process is running.
write_input(pid: str, text: str): Send input to a process.
read_output(pid: str): Read output from a process.
get_processes(): Get a list of all processes.
Local repository configuration:
{
"mcpServers": {
"cli": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-cli", "run", "mcp-cli"]
}
}
}Using it from Github:
{
"mcpServers": {
"cli": {
"command": "uvx",
"args": ["--from", "git+https://github.com/clalarco/mcp-cli", "mcp-cli"]
}
}
}Having npm installed, run:
Local repository:
npx -y @modelcontextprotocol/inspector uv run mcp-cliFrom github:
npx -y @modelcontextprotocol/inspector uvx --from git+https://github.com/clalarco/mcp-cli mcp-cliGet a list of all processes.
Returns: A dictionary of ProcessDetails objects with PID as key. ProcessDetails contains pid, command and is_alive.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides decent transparency: return format and fields are described. However, it does not disclose scope (all system processes or only agent-managed) or any side effects. Adequate but not thorough.
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?
Extremely concise: two short sentences plus a bullet-style return description. No unnecessary words.
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 simple 0-param tool with an output schema, the description covers purpose and return fields adequately. Could mention potential side effects or scope limitations but overall complete enough.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter info (none needed). Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a list of all processes' using a specific verb and resource. It distinguishes from sibling tools like start_program and stop_program by focusing on listing processes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not specify context (e.g., only processes started by agent) or when other tools are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a program is running.
Args: pid: The process ID returned by start_program().
Returns: True if the program is running, False otherwise.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully explains behavior: it returns True/False. It does not mention side effects, but for a read-only check, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It uses a clear structure with Args and Returns sections, making it easy to parse.
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 simplicity and the presence of an output schema, the description covers all necessary aspects: purpose, parameter source, and return value.
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 has 0% description coverage, but the description adds meaning by stating the pid is from start_program(). This compensates for the schema gap, though format details are omitted.
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 checks if a program is running, using a specific verb and resource. It distinguishes itself from sibling tools like start_program and stop_program by focusing on status checking.
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 specifies that the pid argument comes from start_program(), providing clear context. While it doesn't explicitly exclude alternative uses, it gives sufficient guidance for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read available output from a running program.
Args: pid: The process ID returned by start_program(). max_bytes: Maximum number of bytes to read. timeout: Maximum time to wait for output.
Returns: The output text read from the process. Returns empty string if no output.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | ||
| timeout | No | ||
| max_bytes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions that the tool can wait for output via the timeout parameter and returns empty string if no output. However, it does not disclose error behavior (e.g., invalid PID) or whether it is non-destructive.
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 succinct with a clear heading, bulleted args, and a returns statement. Every sentence adds value, and there is no extraneous text.
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 an output schema exists (context signal), the description adequately covers the input parameters and return value. It could mention error cases or blocking behavior, but it is reasonably complete for a read operation.
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 0%, so the description adds meaning for all three parameters. It explains that pid comes from start_program, max_bytes limits reading, and timeout is maximum wait time. This compensates for the missing schema descriptions.
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 it reads available output from a running program, using a specific verb and resource. It naturally distinguishes from sibling tools like write_input, start_program, and wait_for_output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like wait_for_output. The description does not mention any prerequisites, exclusions, or context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a CLI program in a PTY.
Args: command: The command to run (e.g., "cat", "python -i", "ls -la").
Returns: The process ID (pid) of the started program.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'Start a CLI program in a PTY' and returns a pid. Lacks details on side effects, blocking behavior, lifecycle, or interaction model with siblings.
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 short and front-loaded. It efficiently states the purpose and parameters. Minor room for improvement: the Args/Returns format adds structure.
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?
Despite low complexity (1 param, no annotations), the description lacks important context such as asynchronous execution, how to stop the process, or output format details. The output schema is said to exist but not visible, so return pid is mentioned but not structured.
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 coverage is 0%, but description adds examples ('cat', 'python -i', 'ls -la') which helps clarify the command parameter. However, no constraints or formatting guidance beyond the examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Start' and resource 'CLI program in a PTY'. It distinguishes from sibling tools like stop_program, read_output, etc., which manage or interact with processes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, error conditions, or how the started program relates to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop all running programs.
Returns: A confirmation message.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. Description states it stops all programs but does not disclose side effects, permissions, or reversibility. Minimal behavioral info.
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?
One sentence plus return info; no wasted words. Could add structured context but efficient.
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?
With zero params and output schema, description should clarify scope of 'programs' and behavior. Missing details for a potentially destructive action.
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?
No parameters; schema coverage 100%. Baseline 4 applies as description adds no param info.
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?
Clear verb and resource: 'Stop all running programs'. Distinct from siblings like 'stop_program' which implies single program.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs 'stop_program' or other tools. No context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running program.
Args: pid: The process ID returned by start_program.
Returns: A confirmation message.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the stopping action and required pid, but does not mention side effects, error handling, or cleanup behavior.
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?
Three clear, front-loaded sentences with no wasted words. Efficiently structured for quick parsing.
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 simple one-parameter tool, the description covers purpose, parameter source, and return value, making it complete.
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?
Adds meaning to the pid parameter by specifying it is the process ID returned by start_program, which is valuable beyond the schema's type-only definition.
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 'Stop a running program' and the resource 'program'. It distinguishes from siblings like stop_all_programs by implication, but does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., stop_all_programs). Lacks context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait until a specific text pattern appears in the output.
Args: pid: The process ID returned by start_program(). pattern: The text to wait for. timeout: Maximum time to wait in seconds.
Returns: The output captured so far, or an error/timeout message.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | ||
| pattern | Yes | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses behavioral traits: waiting, timeout, returns accumulated output or error/timeout. It could add more about blocking behavior or process termination handling.
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 short and front-loaded, with a clear purpose and structured args/returns. Every sentence is essential, no waste.
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 3 params, no annotations, and an output schema, the description adequately explains inputs and returns (captured output or error/timeout). Could include more on edge cases but sufficient.
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 coverage is 0%, so description fully carries the burden. It explains pid (process ID from start_program), pattern (text to wait for), and timeout (max wait in seconds), adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Wait' and the resource 'until a specific text pattern appears in the output', which is distinct from sibling tools like read_output (reads without waiting) and is_alive (checks process status).
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 waiting on pattern appearance but provides no explicit guidance on when to use this tool over alternatives (e.g., read_output, is_alive) or prerequisites like needing a started process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send text input to a running program.
Args:
pid: The process ID returned by start_program().
text: The text to send. Newlines are usually needed (e.g., "
").
Returns:
A confirmation message.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | ||
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral details: newlines are usually needed and it returns a confirmation message. Could mention error states but sufficient.
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?
Very concise: two sentences and parameter list. No filler, all information 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 sibling tools and output schema, description covers action, parameters, and return. Could add error handling but otherwise complete.
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 has 0% coverage; description explains pid as process ID from start_program and text with newline hint, adding significant meaning beyond schema.
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 'Send text input to a running program,' specifying a verb and resource. It distinguishes from sibling tools like read_output and start_program.
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?
It implies usage after start_program by mentioning pid from start_program, but does not explicitly state when not to use or provide alternatives. Adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_processesis_aliveread_outputstart_programstop_all_programsstop_programwait_for_outputwrite_inputTools are mostly distinct: get_processes lists all, is_alive checks status, start/stop manage lifecycle, read_output reads current output, wait_for_output waits for pattern, write_input sends text. Some minor overlap exists between read_output and wait_for_output, but they serve different purposes (immediate read vs. waiting).
All tool names use snake_case with a verb_noun pattern (e.g., start_program, stop_program). 'is_alive' deviates slightly (adjective_noun) but is still clear. Overall consistent enough for easy prediction.
8 tools is an ideal number for a CLI process management server. Each tool covers a distinct aspect without bloat, making the surface easy to navigate.
Covers core lifecycle (start, stop, list, check status), I/O (write, read, wait for pattern). Lacks a restart or signal-sending tool, but the set is sufficient for most interactive CLI use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP Server for JFrog, providing tools for development and artifact management.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/clalarco/mcp-server-for-cli'
If you have feedback or need assistance with the MCP directory API, please join our Discord server