Which integrations are available for this server?

Allows managing Docker Compose processes and other development servers by starting, stopping, and monitoring them via process management tools.

How do I use procm-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., "@procm-mcp start npm run dev in /home/user/project" 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.

procm-mcp

by coder-ka

Overview Schema Related Servers Score Discussions

JavaScript

Local

procm-mcp

A Model Context Protocol (MCP) server for process management.

Supported features

Secure and automatable process creation
Cleanup created processes automatically on termination (e.g. exiting claude code)
Common process management features supported, restarting, deleting, checking status or retreving stdout/stderr of processes

Using these features, LLMs start processes like development servers, docker-compose, or test watchers and check their outputs to fix bugs automatically.

Related MCP server: interactive-process-mcp

Installation

npm i -D procm-mcp

.mcp.json

{
  "mcpServers": {
    "procm-mcp": {
      "command": "node",
      "args": ["./node_modules/procm-mcp/build/index.js"],
      "env": {}
    }
  }
}

Secure process creation

You can permit LLMs to use start-process tool without confirmation, because procm-mcp only allow whitelisted process creations.

LLMs will ask you to use allow-start-process tool to add specific process creation to the whitelist.

Once you allow a process creation, you don't have to confirming it anymore as long as the command and the working directory are the same.

I call it "allow-x pattern", which can balances security and usability in MCP.

Warning: Do not permit LLMs to use allow-start-process without confirmation.That means "Do anything you want to".

Tools

allow-start-process Allow specific processes to be created
- script (required): The script/command to allow
- args (optional): Array of arguments
- cwd (optional): Working directory
start-process Start a new process with specified script and arguments
- script (required): The script/command to execute
- name (optional): A friendly name for the process
- args (optional): Array of arguments to pass to the script
- cwd (required): Working directory for the process
- envs (optional): Environment variables to set for the process
delete-process Stop and remove a process by ID.The default signal is SIGTERM, but SIGKILL(force killing) will be sent after 10 seconds unless the process exits.
- id (required): The process ID
restart-process Restart an existing process by ID
- id (required): The process ID
get-process-info Get detailed information about a process
- id (required): The process ID
list-processes List all currently managed processes
- No parameters required
get-process-stdout Retrieve stdout logs from a process
- id (required): The process ID
- chunkCount (optional): Number of recent log entries to retrieve (default: 10)
get-process-stderr Retrieve stderr logs from a process
- id (required): The process ID
- chunkCount (optional): Number of recent log entries to retrieve (default: 10)

License

MIT

Available Tools

11 tools

allow-start-processD

Allow process creation

ParametersJSON Schema

Name	Required	Description	Default
`script`	Yes
`args`	No
`cwd`	No

TDQS

D1/5.0

Behavior1/5

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

No annotations provided, and the description fails to disclose behavioral traits such as side effects, permissions, or whether the tool actually starts a process or grants permission. The description is insufficient for a mutation-like tool.

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

Conciseness1/5

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

The description is extremely short but at the expense of meaningful content. It is under-specified, not concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool (3 parameters, multiple siblings, no output schema), the description is completely inadequate. It fails to provide essential context for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no information about the three parameters (script, args, cwd). The description adds no value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Allow process creation' is a tautology that restates the tool name without specifying what 'allow' means or how it differs from siblings like 'start-process'. No verb-resource clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

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 such as 'start-process' or 'delete-allowed-process'. No context provided.

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

delete-allowed-processC

Delete an allowed process

ParametersJSON Schema

Name	Required	Description	Default
`script`	Yes
`args`	No
`cwd`	No

TDQS

C2/5.0

Behavior2/5

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

The word 'Delete' implies mutation, but no details are given about the scope or consequences (e.g., whether it also stops running processes, if it's reversible, or requires permissions). With no annotations, the description should provide more context.

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

Conciseness2/5

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

The description is a single sentence, but it sacrifices essential detail under the guise of conciseness. It does not adequately specify the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema, annotations, and parameter descriptions, the description fails to provide a complete picture. The presence of similar sibling tools makes additional context critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no information about the parameters 'script', 'args', or 'cwd'. Their role in deleting an allowed process is entirely unclear.

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 verb 'delete' and resource 'allowed process', but it's unclear if an 'allowed process' is a configuration or a running process. It does not distinguish itself from the sibling tool 'delete-process'.

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 on when to use this tool versus alternatives like 'delete-process' or 'stop-process'. The description provides no context about appropriate use cases.

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

delete-processC

Delete a process by ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description must carry the behavioral burden. It states 'delete' (a mutation) but does not disclose whether deletion is irreversible, what happens to associated resources, or any authorization requirements.

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 very concise at 5 words, which is appropriate for a simple delete operation. However, it could be slightly more structured with a brief behavioral note.

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 single parameter, lack of output schema, and no annotations, the description provides only the bare minimum. It fails to inform the agent about return behavior, error states, or irreversible consequences.

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%, and the description does not clarify the nature of the 'id' parameter beyond being an identifier. It could specify format or source (e.g., process ID from list-processes).

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 the clear verb 'Delete' and specifies the resource 'process' with the identifier 'by ID'. It is unambiguous within the context of its sibling tools, particularly distinguishing itself from 'delete-allowed-process'.

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 about when to use this tool versus alternatives, nor any prerequisites or side effects. The description lacks context for decision-making.

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

get-process-infoC

Get information about a process by ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose what information is returned, side effects, or required permissions. The absence of behavioral context limits the agent's ability to assess impact.

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 a single, efficient sentence with no extraneous words. It is front-loaded with the core purpose.

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 no output schema, the description should explain what information is returned, but it does not. For a simple retrieval tool, the description is too minimal to be fully informative.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no additional meaning to the 'id' parameter beyond what the schema already indicates (a string identifier). The term 'by ID' merely restates the parameter's role.

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 action ('get information') and the resource ('process') using the identifier ('by ID'). It distinguishes the tool's purpose from siblings that focus on starting, deleting, or listing processes.

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 like 'list-processes' or 'get-process-stderr'. The description does not specify context or exclusions.

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

get-process-stderrC

Get the stderr of a process by ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`chunkCount`	No

TDQS

C2.5/5.0

Behavior2/5

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

Without annotations, the description must disclose behavioral traits. It does not specify if stderr is streamed or captured all at once, if it is destructive, or any authentication needs. Only states the basic action.

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

Conciseness2/5

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

While it is a single sentence and front-loaded, it is too terse. It omits necessary information about parameters and behavior, making it under-specified rather than concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, no annotations, and two undocumented parameters, the description is incomplete for an AI agent to use correctly. It lacks details on return values, pagination, or error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has two parameters with 0% schema description coverage. The description does not explain the 'chunkCount' parameter or provide any details about the 'id' format. The description fails to add meaning beyond the schema structure.

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?

The description clearly states the tool retrieves the stderr of a process by ID, distinguishing it from sibling tools like get-process-stdout and get-process-info.

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 on when to use this tool versus alternatives, such as get-process-stdout for stdout. The description lacks any context about prerequisites or when it is appropriate to call.

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

get-process-stdoutC

Get the stdout of a process by ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`chunkCount`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so description carries full burden. It fails to disclose whether tool is read-only, destructive, permissions required, or effect of chunkCount. Only states basic action.

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?

Single sentence is concise but under-specifies important details. Could be restructured to include more information without verbosity.

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?

No output schema, no annotations, and minimal description. Does not specify return format (e.g., text, JSON) or behavior of chunkCount, leaving agent with insufficient context for correct invocation.

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 coverage is 0%, yet description adds no meaning beyond parameter names. Does not explain chunkCount's purpose (e.g., number of lines/bytes). Id is obvious, but missing semantic depth.

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?

Description clearly states the verb 'Get', resource 'stdout of a process', and method 'by ID'. It distinguishes from sibling tools like get-process-stderr and get-process-info.

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 on when to use this tool versus alternatives like get-process-stderr or start-process. No exclusions or context provided.

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

get-server-idB

Get server id

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description bears the burden of disclosing behavioral traits. It only implies a read operation but does not mention idempotency, authentication, rate limits, or any side effects.

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 a single, concise sentence that efficiently conveys the tool's function. It is appropriately sized for the tool's simplicity.

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?

The description is bare-minimum for a zero-parameter, no-output-schema tool. It could be improved by indicating that the server ID is used in process operations, adding context for the agent's workflow.

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 coverage is 100% (no parameters), so baseline is 3. The description adds no further information about parameters, which is acceptable given the absence of parameters.

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 'Get server id' clearly states the verb and resource, but does not distinguish from sibling tools. However, siblings are all process-related, so the purpose is still unambiguous.

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. The description lacks any context about prerequisites or use cases, leaving the agent without decision support.

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

list-allowed-processes-in-cwdC

List allowed processes in current working directory

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It only states the basic action without disclosing any behavioral traits like whether it is read-only, requires authentication, or has side effects. The brevity 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.

Conciseness3/5

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

The description is a single concise sentence, which is appropriately brief. However, it lacks sufficient informative content to earn a higher score; it is minimally adequate.

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 tool has one parameter, no output schema, and no annotations, the description is incomplete. It does not explain what 'allowed processes' are, how they are determined, or the format of the response. A more descriptive explanation is needed.

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?

The input schema has one parameter 'cwd' with no description (0% coverage). The description does not add any meaning about the parameter beyond its presence. It fails to clarify its purpose, format, or default behavior.

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 'List allowed processes in current working directory', specifying the verb 'list' and the resource 'allowed processes' with a scope qualifier. This distinguishes it from sibling tools like 'list-processes' which likely returns all processes. However, the term 'allowed processes' could be more explicitly defined.

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 such as 'list-processes'. The description does not mention prerequisites or contextual clues for selection.

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

list-processesB

List all running processes

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It does not disclose whether this is a read-only operation, performance implications, or required permissions. A read-only hint or note on the scope (e.g., 'on the current server') would improve transparency.

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?

A single, concise sentence that conveys the essential purpose with no redundant information. It is appropriately front-loaded and easily scannable.

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?

The description is adequate for a simple, parameterless list tool. However, without an output schema, the description could be more complete by mentioning what information is returned (e.g., process names, PIDs).

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 tool has zero parameters, and schema description coverage is 100% (no parameters to describe). With high coverage, the baseline is 3. The description adds no parameter info, which is acceptable given the absence of parameters.

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?

The description 'List all running processes' uses a clear verb ('list') and specific resource ('all running processes'). It differentiates from sibling tools like 'list-allowed-processes-in-cwd' (which filters by directory) and 'get-process-info' (which targets a single process).

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 on when to use this tool versus alternatives. For example, it does not mention that for detailed info on a single process, one should use 'get-process-info', or that for listing allowed processes, one should use 'list-allowed-processes-in-cwd'.

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

restart-processC

Restart a process by ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

C2.3/5.0

Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits beyond restarting. It does not mention whether the action is destructive, requires permissions, or affects process state such as output streams.

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

Conciseness2/5

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

The description is a single short sentence, but it is under-specified and essentially repeats the tool name. It lacks useful details that would justify its existence beyond the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations, a single parameter with no schema description, and no output schema, the description is woefully incomplete. It fails to provide necessary context for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, and the description only mentions 'by ID' without explaining what the 'id' parameter represents or its format. It adds no meaningful context beyond the schema itself.

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?

The description clearly states the verb 'Restart' and the resource 'process', specifying the action to restart a process by its ID. This distinguishes it from sibling tools like start-process, delete-process, and list-processes.

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 like start-process or delete-process. No prerequisites or exclusion conditions are mentioned.

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

start-processB

Start a new process. Warning: Do not invoke background processes that will not exit automatically, and stdout/stderr will not be captured.

ParametersJSON Schema

Name	Required	Description	Default
`script`	Yes
`name`	No
`args`	No
`cwd`	Yes
`envs`	No

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses that stdout/stderr are not captured and warns about lingering background processes. However, it fails to disclose whether the tool blocks, its return value, error handling, or termination behavior.

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?

Two sentences: the first states the core purpose, the second adds critical warnings. No fluff or redundancy. Front-loaded with the essential action.

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?

The description is too sparse for a tool with 5 parameters, no output schema, and no annotations. It omits parameter meanings, return value, synchronization model, and lifecycle management. The warning is helpful but insufficient for complete agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/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 add meaning. It does not describe any of the 5 parameters (script, name, args, cwd, envs) beyond the schema. The warning mentions stdout/stderr but not how parameters relate to that behavior.

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 'Start a new process' with the verb 'Start' and resource 'process'. It distinguishes from siblings like 'allow-start-process' and 'delete-process' by being the actual execution action. However, it doesn't specify whether the process runs synchronously or asynchronously.

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 warning explicitly advises against invoking background processes that won't exit automatically and notes that stdout/stderr will not be captured, providing clear usage context and exclusions. It does not name alternative tools, but the context is sufficient for an agent to decide when to avoid this tool.

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.

11 tool updatesv0.0.43Jun 12, 2026
- First observedallow-start-process
- First observeddelete-allowed-process
- First observeddelete-process
- First observedget-process-info
- First observedget-process-stderr
- First observedget-process-stdout
- First observedget-server-id
- First observedlist-allowed-processes-in-cwd
- First observedlist-processes
- First observedrestart-process
- First observedstart-process

Install Server

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

TDQS

C2.8/5.0

Disambiguation5/5

Each tool targets a distinct action or resource: starting, allowing, deleting, listing, retrieving info, stdout, stderr. No two tools have overlapping purposes; descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern in snake_case (e.g., start-process, get-process-info). Naming is predictable and uniform.

Tool Count5/5

With 11 tools, the server covers process lifecycle management comprehensively without redundancy. The count feels appropriate for the domain.

Completeness4/5

Core operations (start, list, info, restart, delete, output retrieval) are covered. Missing tools like graceful stop or sending input, but the set is sufficient for basic management.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
ArcjetOAuth
com.arcjet
An MCP server for Arcjet - the runtime security platform that ships with your AI code.
Security AI & Machine Learning Code Execution
21
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
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

Related MCP Servers

Shell-MCP
Shell Access Command Line Code Execution
kevinwatt
A
license
B
quality
D
maintenance
A secure MCP server for executing whitelisted shell commands with resource and timeout controls, designed for integration with Claude and other MCP-compatible LLMs.
Updated 2 years ago (2025-02-20 18:14 UTC)
20
389
7
MIT
interactive-process-mcp
Shell Access Command Line
UserB1ank
A
license
A
quality
C
maintenance
MCP server for managing interactive processes, enabling AI agents to start, interact with, and terminate long-running programs like SSH sessions, REPLs, and installers via read/write operations.
Updated 4 months ago (2026-05-06 02:14 UTC)
8
8
MIT
MCP Shell Server
Shell Access Command Line OS Automation
mako10k
A
license
B
quality
A
maintenance
A secure MCP server for shell operations, terminal management, and process control, enabling AI assistants to safely execute commands and manage interactive sessions.
Updated 5 days ago (2026-09-01 07:04 UTC)
13
204
6
MIT
mcp-sidecar
Shell Access Command Line Developer Tools
lsequeiraa
A
license
Not graded
quality
C
maintenance
A lightweight, cross-platform MCP server for managing background processes. Enables AI coding agents to spawn, monitor, and interact with long-lived processes.
Updated a month ago (2026-08-01 08:16 UTC)
MIT

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/coder-ka/procm-mcp'

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