A
licenseNot graded
qualityD
maintenanceMCP server allowing LLMs to execute commands on Windows terminals, including local shells (cmd, PowerShell, bash) and remote SSH connections with a 3-level security model.
MIT
Terminal Controller for MCP
by GongRzhe
MCP 终端控制器
模型上下文协议 (MCP) 服务器，通过标准化接口实现安全终端命令执行、目录导航和文件系统操作。
特征
命令执行：运行具有超时控制和全面输出捕获的终端命令
目录管理：以直观的格式导航和列出目录内容
安全措施：内置安全措施，防止危险命令和操作
命令历史记录：跟踪并显示最近的命令执行
跨平台支持：适用于 Windows 和基于 UNIX 的系统
文件操作：以行级精度读取、写入、更新、插入和删除文件内容
Related MCP server: MCP Server
安装
通过 Smithery 安装
要通过Smithery自动安装 Claude Desktop 的终端控制器：
npx -y @smithery/cli install @GongRzhe/terminal-controller-mcp --client claude先决条件
Python 3.11+
与 MCP 兼容的客户端（例如 Claude Desktop）
安装 UV/UVX（可选，用于 UVX 方法）
方法 1：PyPI 安装（推荐）
直接从 PyPI 安装包：
pip install terminal-controller或者如果您更喜欢使用 UV：
uv pip install terminal-controller方法 2：从源
如果您希望从源代码安装：
克隆此存储库：
git clone https://github.com/GongRzhe/terminal-controller-mcp.git cd terminal-controller-mcp运行安装脚本：
python setup_mcp.py
客户端配置
克劳德桌面
有两种方法可以配置 Claude Desktop 使用终端控制器：
选项 1：使用 UVX（推荐）
将其添加到您的 Claude Desktop 配置文件中：
"terminal-controller": {
"command": "uvx",
"args": ["terminal_controller"]
}选项 2：直接使用 Python
"terminal-controller": {
"command": "python",
"args": ["-m", "terminal_controller"]
}配置路径因操作系统而异：
macOS ：
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows ：
%APPDATA%\Claude\claude_desktop_config.json
光标
对于 Cursor，使用与 Claude Desktop 类似的配置设置。
其他 MCP 客户端
对于其他客户端，请参阅其文档以了解如何配置外部 MCP 服务器。
用法
配置完成后，您可以使用自然语言通过 MCP 客户端与您的终端进行交互：
“在当前目录中运行命令
ls -la”“导航到我的文档文件夹”
“显示我的下载目录的内容”
“显示我最近的命令历史记录”
“读取config.json的内容”
“使用‘print(“Hello World”)’更新我的 script.py 文件中的第 5 行”
“从日志文件中删除第 10 至 15 行”
“在我的文本文件的开头插入一个新行”
API 参考
终端控制器公开以下 MCP 工具：
execute_command
执行终端命令并返回其结果。
参数：
command：要执行的命令行命令timeout：命令超时（秒）（默认值：30）
返回：
命令执行的输出，包括 stdout、stderr 和执行状态
get_command_history
获取最近的命令执行历史记录。
参数：
count：返回的最近命令数（默认值：10）
返回：
格式化的命令历史记录
get_current_directory
获取当前工作目录。
返回：
当前工作目录的路径
change_directory
更改当前工作目录。
参数：
path：切换到的目录路径
返回：
操作结果信息
list_directory
列出指定目录中的文件和子目录。
参数：
path：列出内容的目录路径（默认值：当前目录）
返回：
目录内容列表，使用目录和文件的图标格式化
write_file
使用覆盖或附加选项将内容写入文件。
参数：
path：文件路径content：要写的内容mode：写入模式（'覆盖'或'附加'，默认值：'覆盖'）
返回：
操作结果信息包括写入成功的验证
read_file
从文件中读取内容，并可选择行。
参数：
path：文件路径start_row：读取的起始行（从 0 开始，可选）end_row：读取的结束行（从 0 开始，包含 0，可选）
返回：
文件内容或选定的行
insert_file_content
在文件的特定行插入内容。
参数：
path：文件路径content：要插入的内容row：要插入的行号（从 0 开始，可选）rows：要插入的行号列表（从 0 开始，可选）
返回：
操作结果信息
delete_file_content
从文件中删除特定行的内容。
参数：
path：文件路径row：要删除的行号（从 0 开始，可选）rows：要删除的行号列表（从 0 开始，可选）
返回：
操作结果信息
update_file_content
更新文件中特定行的内容。
参数：
path：文件路径content：放置在指定行的新内容row：要更新的行号（从 0 开始，可选）rows：要更新的行号列表（从 0 开始，可选）
返回：
操作结果信息
安全注意事项
终端控制器实施了多项安全措施：
超时控制以防止长时间运行的命令
危险命令黑名单（rm -rf /、format、mkfs）
正确的错误处理和命令执行的隔离
仅访问明确授予的命令和目录
限制
只有在超时时间内完成的命令才会返回结果
默认情况下，服务器具有与运行它的用户相同的文件系统权限
由于终端界面的非交互特性，某些交互式命令可能无法按预期工作
故障排除
如果您遇到问题：
检查你的 Python 版本是否为 3.11 或更高版本
验证您的 Claude Desktop 配置是否正确
尝试直接运行终端控制器来检查错误：
python -m terminal_controller对于与 UVX 相关的问题，请尝试：
uvx terminal_controller检查 MCP 客户端日志中的连接错误
贡献
欢迎贡献代码！欢迎提交 Pull 请求。
执照
麻省理工学院
Available Tools
10 toolschange_directoryC
Change current working directory
Args:
path: Directory path to switch to
Returns:
Operation result information
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic action without mentioning side effects (e.g., permission requirements, error handling, or navigational boundaries). The return value 'Operation result information' is vague.
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 short and straightforward, with a clear header and an Args section. It avoids unnecessary text, though placing the key purpose first is good practice but not explicitly front-loaded due to the structure.
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 lack of annotations and output schema, the description should provide more context about return values, error cases, and interaction with sibling tools. It does not mention that other tools like get_current_directory complement this operation.
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 schema has 0% parameter description coverage, so the description compensates slightly by naming the parameter 'path' and adding 'Directory path to switch to'. However, it does not specify path types (absolute/relative), validation, or format, leaving ambiguity beyond the parameter name.
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 'Change current working directory', which is a specific verb+resource (change directory) that directly conveys the action. However, it does not explicitly differentiate from sibling tools like execute_command or list_directory, though the purpose is 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 such as get_current_directory or execute_command. The description does not mention prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_file_contentA
Delete content at specific row(s) from a file
Args:
path: Path to the file
row: Row number to delete (0-based, optional)
rows: List of row numbers to delete (0-based, optional)
substring: If provided, only delete this substring within the specified row(s), not the entire row (optional)
Returns:
Operation result information
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| row | No | ||
| rows | No | ||
| substring | No |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that substring deletion only removes the substring within the row, not the entire row. However, with no annotations, it fails to mention destructive nature, error handling, or index behavior (e.g., shifting after deletion).
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 structured with Args and Returns, and each parameter is explained in a single line. It is not overly verbose, though it could omit 'Args:' and 'Returns:' for brevity.
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 destructive tool with no annotations and no output schema, the description omits important details: error cases (e.g., invalid row), behavior when both row and rows are provided, and return value. This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds full meaning: row is 0-based integer, rows is list, substring optional for partial deletion. This compensates entirely for the missing schema explanations.
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 deletes content at specific rows from a file, using a specific verb and resource. It distinguishes from siblings like update_file_content and insert_file_content by focusing on deletion.
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 on when to use this tool versus alternatives such as update_file_content or write_file. The description lacks context for choosing between row deletion and substring deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
execute_commandB
Execute terminal command and return results
Args:
command: Command line command to execute
timeout: Command timeout in seconds, default is 30 seconds
Returns:
Output of the command execution
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| timeout | No |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description lacks disclosure of safety, side effects, or return format. For a command execution tool, this is insufficient 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?
Very concise with a clear Args/Returns structure. Every sentence is meaningful and there is no wasted text.
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 potentially dangerous tool, the description is too minimal. It lacks information on error handling, return format, timeout behavior, and prerequisites.
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 0%, but the description adds basic meaning: 'command' is a command line string, 'timeout' is in seconds with default 30. This helps but doesn't specify constraints or format details.
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's purpose: executing terminal commands and returning results. It distinguishes itself from sibling tools like file operations and directory navigation.
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. Sibling tools are listed but the description gives no context for choosing execute_command over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_command_historyB
Get recent command execution history
Args:
count: Number of recent commands to return
Returns:
Formatted command history record
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it gets history without disclosing data freshness, persistence, or side effects. Unclear what 'recent' means.
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?
Concise single sentence followed by technical docstring. Front-loaded main action with minimal redundancy.
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; description says returns 'Formatted command history record' which is vague. Missing details on whether it returns a list, string, or structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds explanation for 'count' parameter beyond schema, specifying it controls how many commands to return. Schema coverage is 0%, so this is helpful, though could be more precise.
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?
Clearly states it retrieves recent command execution history. Distinct from sibling execute_command which runs commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like execute_command. Lacks context about prerequisites or scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_current_directoryA
Get current working directory
Returns:
Path of current working directory
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It only states the basic function and return value but does not disclose any behavioral traits like permissions, failure modes, or 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?
Extremely concise: two sentences, no wasted words. The purpose is front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, this description is complete. It states what the tool does and what it returns, which is sufficient for such a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds no parameter semantics beyond the schema, but according to rules a zero-parameter tool gets a baseline of 4.
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 'Get current working directory' which is a specific verb+resource. It distinguishes itself from sibling tools like change_directory (which changes directory) and list_directory (which lists contents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives. There is no mention of context or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insert_file_contentB
Insert content at specific row(s) in a file
Args:
path: Path to the file
content: Content to insert (string or JSON object)
row: Row number to insert at (0-based, optional)
rows: List of row numbers to insert at (0-based, optional)
Returns:
Operation result information
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| content | Yes | ||
| row | No | ||
| rows | No |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description omits behavioral details such as what happens if the file does not exist, if the row index is out of range, or whether the operation can be reversed. The return value is vaguely described as 'Operation result information'.
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 short and begins with the main purpose, then lists parameters in a clear format. However, the docstring-style repetition of parameter info could be more streamlined.
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 lack of annotations and output schema, the description should provide more context about return values, error behavior, and edge cases. It only covers basic parameter semantics, leaving gaps in understanding how the tool behaves in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter's purpose, including that 'row' and 'rows' are 0-based. It also notes that 'content' can be a string or JSON object, adding value beyond the schema's type string.
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 action ('Insert content') and the resource ('at specific row(s) in a file'). This is distinct from sibling tools like 'write_file' (overwrite) or 'update_file_content' (modify existing content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives such as 'write_file' or 'update_file_content'. It does not mention prerequisites or scenarios where insertion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_directoryA
List files and subdirectories in the specified directory
Args:
path: Directory path to list contents, default is current directory
Returns:
List of directory contents
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states the basic operation. It does not disclose behaviors such as whether hidden files are listed, how errors (e.g., invalid path) are handled, or if it follows symlinks. For a simple tool, this is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a clear statement of purpose followed by parameter details. Every sentence is informative, though the Args/Returns format is somewhat verbose for such a simple tool.
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 the tool's simplicity and the lack of output schema, the description adequately covers the input and output. It explains the single parameter and the return value (list of contents), which is sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'path' parameter by explaining its purpose and default value, which is not fully conveyed by the schema alone (which only specifies type and nullability). Schema coverage is 0%, so the description compensates well.
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 'list' and the resource 'files and subdirectories' in a specified directory, which distinguishes it from sibling tools like read_file or write_file.
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 change_directory or read_file. It does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_fileA
Read content from a file with optional row selection
Args:
path: Path to the file
start_row: Starting row to read from (0-based, optional)
end_row: Ending row to read to (0-based, inclusive, optional)
as_json: If True, attempt to parse file content as JSON (optional)
Returns:
File content or selected lines, optionally parsed as JSON
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| start_row | No | ||
| end_row | No | ||
| as_json | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are present, the description explains that the tool returns file content (optionally as JSON) and selects rows. It implicitly indicates a read-only operation, which is sufficient for this straightforward tool.
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 concise, using a clean Args/Returns format. Every sentence adds value, with no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 adequately explains return values (file content or selected lines, optionally as JSON). All four parameters are covered, and the tool's simple behavior is fully described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by detailing each parameter's purpose, type, and defaults (e.g., 0-based rows, optional as_json). This fully clarifies parameter usage.
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 'Read content from a file' specifying the verb and resource. It is distinct from sibling tools like write, delete, or execute commands, making its purpose 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 relative to alternatives such as list_directory or execute_command. The description lacks context on when reading a file is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_file_contentA
Update content at specific row(s) in a file
Args:
path: Path to the file
content: New content to place at the specified row(s)
row: Row number to update (0-based, optional)
rows: List of row numbers to update (0-based, optional)
substring: If provided, only replace this substring within the specified row(s), not the entire row
Returns:
Operation result information
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| content | Yes | ||
| row | No | ||
| rows | No | ||
| substring | No |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that it updates content at specific rows, optionally only replacing a substring. It does not explicitly state that the operation is destructive or what happens to other rows, but the 'update' verb implies mutation. This is fairly transparent but could be more explicit.
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 structured as a concise docstring with clear Args and Returns sections. Each parameter is explained in a single line, and there is no wasted verbiage. It efficiently conveys the necessary information.
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 covers all parameters and returns 'Operation result information', which is generic. However, it does not specify what happens when row or rows are omitted (e.g., does it update the entire file?), nor does it mention file existence or error conditions. This leaves some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The JSON schema has no descriptions (0% coverage), so the description fully compensates by explaining each parameter: path, content, row (0-based optional), rows (list optional), and substring (optional replacement). This adds significant meaning beyond 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 clearly states 'Update content at specific row(s) in a file', which specifies the verb and resource. It distinguishes from siblings like delete, insert, or write by targeting specific rows, making it clear when this tool is appropriate.
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 action but does not explicitly state when to use this tool over alternatives like write_file or insert_file_content. However, the focus on row-level updates implies its use case, and the description is adequate for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write_fileB
Write content to a file
Args:
path: Path to the file
content: Content to write (string or JSON object)
mode: Write mode ('overwrite' or 'append')
Returns:
Operation result information
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| content | Yes | ||
| mode | No | overwrite |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions write mode (overwrite/append) but fails to clarify file creation, directory creation, permissions, error handling, or character encoding.
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?
Concise docstring with clear sections. Each sentence provides value, though the Returns section is vague. No wasted words.
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 low schema coverage, the description covers the basics but lacks details on return values, edge cases (e.g., path exists, directory missing, large files). Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions (0% coverage). The description compensates by explaining each Arg, noting content can be string or JSON object, and listing mode options.
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 'Write content to a file' with a specific verb and resource. It effectively distinguishes from sibling tools like read_file, delete_file_content, etc.
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 vs alternatives (e.g., append vs overwrite, or use insert_file_content for inline edits). Lacks any when-to-use or when-not-to-use context.
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.
10 tool updates
- First observed
change_directory - First observed
delete_file_content - First observed
execute_command - First observed
get_command_history - First observed
get_current_directory - First observed
insert_file_content - First observed
list_directory - First observed
read_file - First observed
update_file_content - First observed
write_file
TDQS
A3.7/5.0
Scored across 10 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: directory change/get/list, file read/write/insert/update/delete, command execution, and history retrieval. No overlapping functionality.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case, using imperative verbs like change, delete, execute, get, insert, list, read, update, write. The naming is predictable and uniform.
Tool Count5/5
With 10 tools, the set is well-scoped for a terminal controller, providing essential file and directory operations plus command execution without oversaturation.
Completeness4/5
The surface covers core file CRUD (create via write, read, update, delete) and directory navigation, plus command execution and history. Missing directory creation/deletion and file copy/move, but these are minor gaps for typical agent workflows.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA modular MCP server providing file operations, web search, URL scraping, and sandboxed command execution for LLM interactions.1MIT
- AlicenseBqualityAmaintenanceA secure MCP server for shell operations, terminal management, and process control, enabling AI assistants to safely execute commands and manage interactive sessions.13172 npm6MIT
- AlicenseNot gradedqualityBmaintenanceA local MCP server that enables LLMs to execute shell commands on remote hosts over SSH with multiple authentication methods.35 npm3MIT