MCP Shell Server

by mako10k

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v2.8.1
Disambiguation4/5
Most tools have clear, distinct purposes: shell_execute runs commands, process_get_execution retrieves execution details, and the various output/cleanup tools each handle different aspects. Some overlap exists between shell_execute and terminal_operate, and among cleanup-related tools, but descriptions clarify the boundaries.
Naming Consistency3/5
Naming follows a general pattern with verbs like list, read, delete, get, close, and terminal_ prefix for terminal tools, but there are inconsistencies such as shell_execute vs process_get_execution, shell_set_default_workdir, and perform_auto_cleanup. The mixed styles (e.g., verb_noun vs noun_verb_noun) are readable but not uniform.
Tool Count5/5
13 tools is well-scoped for a shell server covering execution, process info, output management, cleanup, terminal sessions, and history. Each tool contributes to the core domain without excessive redundancy.
Completeness4/5
The tool surface covers the main lifecycle: execute commands, retrieve status, manage outputs, cleanup, and query history. Minor gaps include lack of a forceful process termination tool and no direct way to modify or cancel a running execution, but most workflows are supported.
Average 3.4/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on September 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
No annotations are provided, so the description alone must disclose the tool's behavioral traits. It only says 'set default working directory' without explaining persistence, session scope, how to reset, or side effects on subsequent commands. The description does not contradict annotations (none exist) but fails to expose key behavioral facts.
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, straightforward sentence that states the action and object clearly without unnecessary words. It front-loads the primary function. It is appropriately sized for a simple setter tool, though it could be expanded with usage context without losing 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 tool's simplicity (one parameter, no output schema), the description is minimal but incomplete: it does not state the scope of the setting (e.g., whether it applies to all subsequent executions), how it interacts with shell_execute, or any reset mechanism. The schema describes the parameter but the tool's broader execution context is left to inference.
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%, so the sole working_directory parameter is already documented in the schema. The description adds little beyond restating that it sets the directory, which is essentially the parameter's purpose. Hence a baseline 3 is appropriate; the description provides no extra parameter details.
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 action ('Set') and a clear resource ('default working directory for command execution'), which distinguishes it from execution and observation tools among the siblings. It is not a tautology and gives enough to understand the core purpose, though it doesn't explicitly name alternatives.
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 given on when to use this tool vs. shell_execute or terminal_operate. The phrase 'for command execution' hints that it is a prerequisite, but there is no explicit statement of when to use or when not to use it, nor any alternative naming.
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, the description carries full responsibility for disclosing behavior. It only states 'Close terminal session' without mentioning that closing terminates all processes in the terminal, any side effects, or whether history saving is affected. Significant behavioral details are absent.
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 sentence with no wasted words, achieving high conciseness. It is appropriately front-loaded with the action, though it could benefit from a bit more context without becoming 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?
For a tool that closes a terminal, the description is too sparse. It does not explain the outcome of closing (e.g., process termination, session cleanup) or what the agent can expect in response. Given no output schema, the description should clarify the result, but it remains minimal.
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% for both parameters (terminal_id and save_history), and each has a detailed description. The tool description adds no extra parameter information, but the schema already fully documents them, making the baseline of 3 appropriate.
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 'Close terminal session' clearly states a specific verb (close) and resource (terminal session), effectively distinguishing it from sibling tools like terminal_operate or terminal_list. It is concise but unambiguous about the action performed.
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 explicit guidance is provided on when to use this tool versus alternatives like terminal_operate or shell_execute. No prerequisites or conditions are mentioned, leaving the agent to infer usage from the name and description alone.
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 of behavioral disclosure. 'Get' implies a read operation, but the description does not explicitly state whether the tool is read-only, whether it makes any state changes, or what happens for invalid terminal IDs. There is no mention of side effects or internal 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 description is extremely concise with no fluff. It clearly states the core action. However, it is so brief that it misses key context; still, for a simple single-parameter read tool, brevity can be considered appropriate.
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?
With no output schema and no annotations, the description should explain what 'detailed information' includes and how it differs from terminal_list. It does not mention return format, possible errors, or behavior. The tool is simple enough that a slightly richer description would have been sufficient, but it currently lacks completeness.
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%, so the parameter terminal_id is already well-documented with its source and purpose. The description adds no additional parameter meaning, but the schema covers it adequately; hence baseline 3 applies.
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?
Description states a clear verb-resource pair: 'Get terminal detailed information'. However, it does not differentiate from sibling tools like terminal_list, which likely also returns terminal information, so there is a slight ambiguity about which tool returns overview vs details.
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 main description gives no guidance on when to use this tool versus alternatives. The parameter schema hints that terminal_id comes from terminal_create or terminal_list and that this gets details for a specific session, but this is not stated in the tool description itself. There is no explicit mention of exclusions or when to prefer sibling tools.
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 only says 'List active terminal sessions' and does not disclose whether the operation is read-only, what the response looks like, whether pagination is supported (though implied by 'limit'), or what the default status behavior is. This leaves important behavioral traits unstated.
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 concise sentence with no unnecessary words, which earns points for brevity. However, it is so terse that it omits useful behavioral detail, so it is not fully effective despite being 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?
With no output schema and no annotations, the description should provide some context about return values and how results relate to sibling tools. It does not explain what the response contains, whether terminal identifiers are returned, or how to use results with terminal_get_info or terminal_operate. The default status behavior is also ambiguous given the status_filter parameter.
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 and provides detailed meanings for all three parameters, including the limit range, status enum values, and substring matching semantics. The description itself adds no parameter information, so the baseline of 3 is appropriate.
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 a specific verb ('List') and resource ('active terminal sessions'). It differentiates from sibling operations like terminal_operate and terminal_close by focusing on listing, though it does not explicitly name them. The word 'active' is slightly inconsistent with the status_filter parameter that allows idle and all.
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 given on when to use this tool versus alternatives like terminal_get_info or terminal_operate. There is no mention of typical workflows, prerequisites, or conditions that would make this tool the right choice. The agent must infer usage solely from the name and schema.
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?
没有注解，描述承担全部行为披露责任。它提及了自动位置跟踪和限制模式下的不可用性，提供了部分行为约束；但未说明权限要求、影响范围、失败行为或返回内容，对18个参数的综合操作工具来说信息仍偏少。
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?
描述简短且有信息密度，将核心功能列在句首，随后补充关键限制。没有冗余，但内容非常少，对一个多功能工具来说略过于简略，故不能给出满分的5分。
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?
考虑到工具包含18个参数、嵌套对象且无输出 schema，描述只提供一个高度概括的定义，没有解释参数之间的协作，比如何时可新建会话、何时复用 terminal_id。对智能体正确调用来说，上下文仍不充分。
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 的字段描述覆盖率达100%，所有参数在 schema 中均有说明。描述并未额外提供参数关联性或使用层面的语义，例如 terminal_id 与 command 条件的关系，符合高覆盖下的 baseline 3分。
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?
描述以一个明确的动名词序列（create sessions, send input, get output）配上资源（host terminals）开头，能够让智能体立即理解工具职责。但它没有与兄弟工具（如 shell_execute、terminal_get_info）做区分，也没有指出自己与这些工具的分界，因此不是最高的5分。
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?
描述完全没有说明何时使用本工具而非兄弟工具（如 shell_execute 用于直接执行命令），也没有给出任何流程性的使用指引。唯一提及的‘在限制模式下不可用’是环境限制而非选择条件。
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?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool analyzes directory size and file age, and the words 'suggestions' and 'recommend' strongly imply a non-destructive read operation. However, it never explicitly states that no files are deleted or modified, which is a meaningful gap given the existence of the perform_auto_cleanup sibling. No contradiction with annotations exists because none were provided.
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 first sentence is front-loaded and effective. However, the second sentence ('Analyzes current directory size and file age to recommend cleanup candidates') and the third sentence ('Help manage disk usage by identifying old or large files') substantially overlap, since old files correspond to file age and large files correspond to directory size. The redundancy means not every sentence earns its place.
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 simple tool with three optional, fully documented parameters, the core invocation details are present. Given there is no output schema, the description could reasonably be expected to hint at the return format (e.g., what a recommendation contains: file paths, sizes, warnings) and to state explicitly that the tool never mutates data. Those two gaps keep it from being complete.
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%, so the schema already documents all three parameters with defaults and meanings. The description adds only high-level conceptual alignment (directory size maps to max_size_mb, file age maps to max_age_hours, warnings map to include_warnings) without new semantic detail, which matches the baseline of 3.
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 opening sentence, 'Get automatic cleanup suggestions for output file management,' names a specific verb, resource, and scope, and the following sentence states the concrete analysis criteria (current directory size, file age). It implicitly distinguishes itself from siblings like perform_auto_cleanup and delete_execution_outputs by framing the output as 'suggestions' rather than actions, but it never names those alternatives or explicitly states that no cleanup is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Helps manage disk usage by identifying old or large files' gives a reasonable usage context, but there is no explicit when-to-use versus when-not-to-use guidance, no stated exclusions, and no mention of the relevant siblings (perform_auto_cleanup, delete_execution_outputs) that would perform the actual deletion. The intended use is implied rather than spelled out.
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 present, so the description carries the full burden. It discloses the key behaviors: deletes files based on age, supports dry-run, and preserves recent files. However, it does not mention whether deletions are permanent, require permissions, or are reversible, which would be important for a destructive cleanup operation.
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 concise sentences with no fluff. The core purpose is stated first, followed by key capabilities (dry-run and configurable retention). Every word earns its place.
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 that there is no output schema and no annotations, the description is moderate. It covers the essential behavior and options adequately for an agent to invoke the tool, but lacks safety guidance (e.g., recommend dry-run first, confirm permanent deletion). For a destructive operation, slightly more context would improve completeness.
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 covers 100% of parameters with clear descriptions, so the schema already documents dry_run, max_age_hours, and preserve_recent. The description adds no new parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.
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 a specific action ('perform automatic cleanup') and target ('old output files'), with criteria ('age and retention policies'). It distinguishes itself from siblings like get_cleanup_suggestions (suggestions vs execution) and delete_execution_outputs (targeted deletion vs age-based cleanup), though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when automatic cleanup based on age is desired) and mentions dry-run and preserving recent files, but it does not explicitly state when not to use it or point to alternative sibling tools. Usage context is implied rather than explicitly specified.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that the tool is universal, supports pagination, search, analytics, and entry references, and that include_full_details toggles metadata vs. full details. However, it does not disclose the response shape (e.g., whether analytics results differ structurally), default pagination behavior, or how filters interact. The description mentions pagination but lacks details like defaults and limits, which is a moderate gap.
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 paragraph with a clear lead sentence, a capability list, and a routing instruction. It is front-loaded with the universal query role and avoids excessive length. The list of capabilities is concise, although it reads somewhat like a feature dump rather than a tight behavioral contract.
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 12 parameters, no annotations, and no output schema, the description covers the main capabilities and one routing hint, but remains incomplete. It does not specify return formats, defaults, or behavior for edge cases like combining analytics_type with query filters. Given the tool's complexity, a more complete description would add operational specifics.
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%, so the schema already documents all 12 parameters. The description adds high-level grouping (pagination, search, analytics, entry references) that maps to the schema, but it does not add meaning beyond what the schema provides. A few parameters like analytics_type and include_full_details are mentioned in the description, but not with additional detail beyond the 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 states a specific verb ('query') and resource ('command history') and enumerates distinct capabilities (pagination, search, entry refs, analytics). It names one sibling it is not ('avoiding duplication with process_get_execution'), which helps differentiation. However, it does not systematically distinguish among the other sibling tools (e.g., list_execution_outputs, read_execution_output) beyond naming one alternative, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for all command history operations' and warns against using it for entry references via execution_id to avoid duplication with process_get_execution. This gives clear when-to-use guidance and one key exclusion, but it does not explicitly state when to use alternatives like list_execution_outputs or read_execution_output.
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 shoulders the full burden. It states the tool lists all outputs and supports filtering, but does not disclose behavior like pagination limits beyond the schema default, ordering, return structure, or whether it only returns metadata. These gaps are notable for a list tool.
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?
Two sentences, front-loaded with the core action and scope. The list of output types is slightly redundant with the output_type enum, but the description is otherwise efficient and well ordered.
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 no output schema and no annotations, a complete description should mention what the returned list contains, any pagination behavior, and how to use the limit parameter effectively. The description covers filtering well but omits these practical details, making it adequate but not comprehensive.
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%, so the schema already fully documents each parameter. The description adds a high-level mention of filtering but no extra semantic value beyond what the parameter descriptions provide. Baseline 3 is appropriate.
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 uses a specific verb ('List') and resource ('output files generated by command executions'), and enumerates content scope (stdout, stderr, log files). It clearly distinguishes from sibling 'read_execution_output' by focusing on listing multiple files rather than reading one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering/listing output files and mentions filtering options, but it does not explicitly state when to prefer this over siblings like 'read_execution_output' or 'delete_execution_outputs'. No exclusion or alternative guidance is given.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose truncation behavior, output retention, pipeline support, and adaptive execution. However, for an arbitrary shell command executor, it does not mention potential side effects, permission requirements, sandbox restrictions, or that commands may modify the system.
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 front-loaded with the core purpose and is reasonably compact. The note about VS Code parameters is somewhat extra but helps prevent common misuse. Each sentence contributes useful context without excessive verbosity.
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?
This is a complex tool with 17 parameters and no output schema, so the description must partly explain return behavior. It covers output_id and output_truncated, but it does not describe the full return value or how immediate stdout/stderr and exit status are surfaced, leaving a meaningful gap for an agent.
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%, so the baseline is 3. The description adds some cross-parameter meaning by linking output_id to read_execution_output and output_truncated to max_output_size, but most parameter semantics are already thoroughly covered by the schema.
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 opens with a specific verb and resource: 'Execute shell commands.' It further distinguishes itself from related tools by explaining bounded output retention and explicitly referencing read_execution_output, making its role clear among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context about output retention, output_id, adaptive mode, and pipeline operations, and it warns against VS Code-specific parameters. However, it does not explicitly state when to use this tool versus sibling tools such as terminal_operate, process_get_execution, or command_history_query, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral disclosure. It reveals that this tool cannot circumvent the server's max_output_size and that output_truncated=true signals discarded data, providing memory-protection context. Read-only nature is conveyed by the name and verb 'Read'.
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 two-sentence description is tightly packed with no filler; it states the core operation first, then a key caveat. That caveat earns its place by preventing a false assumption about truncation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool likely returns output content plus a truncation flag, and enough is implied by the parameter docs and description. Since no output schema exists, a bit more explicit return-format information would make it fully complete, but nothing necessary for invoking the tool is missing.
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?
All four parameters have detailed descriptions in the schema, including defaults, ranges, encoding guidance, and how to obtain output_id. The top-level description does not add extra parameter meaning, so the baseline for 100% schema coverage applies.
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?
Description clearly says 'Read retained output from a command execution', naming the action and target resource. It does not explicitly mention sibling tools, but reading an output is distinct from listing/executing it. The 'retained output' phrase clarifies this operates on pre-existing results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or alternative tool guidance. The note that output_id does not bypass max_output_size offers a boundary condition, and the output_id schema says IDs come from list_execution_outputs, but the main description leaves usage decisions mostly implicit.
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?
With no annotations, the description carries the full burden. It mentions the mandatory confirmation flag to prevent accidental deletion, which signals destructive behavior, but does not explicitly state permanence, irreversibility, or potential side effects beyond what the schema already conveys.
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?
Three short sentences, each earning its place: the action, the safety requirement, and the typical use case. Information is front-loaded and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with well-documented schema and clear safety guidance, the description is reasonably complete. The only gap is lack of explicit differentiation from perform_auto_cleanup, which could affect tool selection in cleanup scenarios.
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%, and both parameters have detailed descriptions in the schema. The tool description adds no extra parameter nuance, so the baseline of 3 applies.
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 states a specific verb ('Delete'), a clear resource ('output files'), and the identifier used ('output_ids'). This distinguishes it from sibling tools like list_execution_outputs and read_execution_output without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context ('cleanup after processing results'). However, it does not explicitly mention when to avoid this tool or how it relates to perform_auto_cleanup, leaving some selection inference to the agent.
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?
With no annotations, the description carries the burden of behavioral disclosure. It lists the returned information (status, output, execution time, errors) but does not mention side effects, permissions, or distinction from other read-oriented sibling tools. Since this is a retrieval operation, some traits are implied but not fully disclosed.
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 succinct sentences: the first states the core function and content, the second supplies the required parameter source. No fluff, and essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single-parameter tool with no output schema, the description provides adequate context about what the tool returns and how to obtain the required ID. It could further differentiate from sibling tools that also access execution outputs, but it is complete enough for effective invocation.
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%, so the schema already fully documents the execution_id parameter. The description repeats the same guidance ('Use the execution_id returned from shell_execute') without adding new semantic detail, thus meeting but not exceeding the baseline.
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 states a specific verb ('Retrieve') and resource ('detailed information about a specific command execution') and enumerates the content (status, output, execution time, errors). It clearly distinguishes this tool from siblings like shell_execute by indicating it is a follow-up retrieval step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to use the execution_id returned from shell_execute, providing clear contextual usage. It does not explicitly mention when not to use this tool or name alternatives like list_execution_outputs, but the usage context is well implied.
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:

[![mcp-shell-server MCP server](https://glama.ai/mcp/servers/mako10k/mcp-shell-server/badges/card.svg)](https://glama.ai/mcp/servers/mako10k/mcp-shell-server)

Score Badge

Copy to your README.md:

[![mcp-shell-server MCP server](https://glama.ai/mcp/servers/mako10k/mcp-shell-server/badges/score.svg)](https://glama.ai/mcp/servers/mako10k/mcp-shell-server)

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/mako10k/mcp-shell-server'

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