Which integrations are available for this server?

Integrates the DuckDuckGo MCP server into the gateway, enabling web search capabilities through DuckDuckGo.

How do I use Agentic Terminal?

1. Click on "Deploy 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., "@Agentic Terminal Create calculator.py with add, subtract, multiply, divide, then run it and verify output." 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.

Agentic Terminal

by mohamedmahmoud8801

Overview Schema Source Related Servers Discussions Admin

Python

Local

Mohamed Agentic Terminal

Turn AI agents into coding assistants that can execute commands, write Python code, manage files, and explore codebases through the Model Context Protocol (MCP).

mohamed-agentic-terminal is an MCP server that gives AI applications access to terminal execution, Python scripting, file management, and code search tools.

Connect it to an MCP-compatible client and let AI agents perform practical development tasks instead of only generating code as text.

✨ Features

The package exposes nine tools:

Tool	Description
`bash`	Execute shell commands.
`python_code`	Execute Python code directly.
`python_file`	Create and execute Python scripts.
`glob`	Find files using glob patterns.
`grep`	Search file contents for matching text.
`read_file`	Read file contents.
`write_file`	Create or update files.
`create_folder`	Create directories.
`delete_folder`	Delete directories.

Related MCP server: Shell Server

📦 Installation

Option 1: Run with `uvx`

You can run the MCP server without manually installing it into your project.

First, install uv if you haven't already.

Then run:

uvx --from mohamed-agentic-terminal agentic_terminal

Option 2: Install in a Python project

If your project uses uv, run:

uv add mohamed-agentic-terminal

🔌 Connect to an MCP Client

Configure your MCP-compatible client to launch the server using uvx.

Example configuration:

{
  "mcpServers": {
    "agentic_terminal": {
      "transport": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "mohamed-agentic-terminal",
        "agentic_terminal"
      ]
    }
  }
}

The configuration format may differ between MCP clients. Adapt the settings to your client's requirements if necessary.

🤖 Usage with LangChain and Ollama

This example demonstrates how to connect the MCP server to a LangChain agent using a local language model through Ollama.

Step 1: Create a project

uv init agentic-terminal-demo
cd agentic-terminal-demo
uv add langchain langchain-mcp-adapters langchain-ollama

Step 2: Install and prepare Ollama

Install Ollama if it isn't already installed.

Download the model:

ollama pull qwen2.5:7b-instruct

Make sure Ollama is running before executing the example.

Step 3: Create `agent.py`

import asyncio

from langchain.agents import create_agent
from langchain_mcp_adapters.client import MultiServerMCPClient
from langchain_ollama import ChatOllama


async def main():
    # Connect to the MCP server
    client = MultiServerMCPClient(
        {
            "terminal": {
                "transport": "stdio",
                "command": "uvx",
                "args": [
                    "--from",
                    "mohamed-agentic-terminal",
                    "agentic_terminal",
                ],
            }
        }
    )

    # Discover the available MCP tools
    tools = await client.get_tools()

    print("Available tools:")
    for tool in tools:
        print(f"- {tool.name}")

    # Initialize the local LLM
    model = ChatOllama(
        model="qwen2.5:7b-instruct",
        temperature=0,
    )

    # Create the AI agent
    agent = create_agent(
        model=model,
        tools=tools,
        system_prompt=(
            "You are a coding assistant. "
            "Use the available tools to create, inspect, "
            "and execute code when needed."
        ),
    )

    # Define a coding task
    task = """
    Create a Python file named calculator.py with functions for:
    - Addition
    - Subtraction
    - Multiplication
    - Division

    Handle division by zero.
    Include a small demonstration in the script.
    Run the script and verify that it works.
    """

    # Execute the task
    result = await agent.ainvoke(
        {
            "messages": [
                {
                    "role": "user",
                    "content": task,
                }
            ]
        }
    )

    print("\nAgent response:")
    print(result["messages"][-1].content)


if __name__ == "__main__":
    asyncio.run(main())

Step 4: Run the agent

uv run python agent.py

The agent discovers the available MCP tools and can call them to complete the requested task.

In this example, the agent is asked to create a calculator script, execute it, and verify the result.

After execution, inspect the generated calculator.py file and run it independently if needed:

cat calculator.py
python calculator.py

Note: The example uses a local Ollama model, but you can adapt it to another model supported by your LangChain integration.

💡 Use Cases

1. AI Coding Assistants

Build agents that can:

Generate Python scripts.
Execute code and inspect the results.
Read error messages and attempt corrections.
Modify existing source files.

2. Codebase Exploration

Allow agents to:

Search for files by pattern.
Find matching text in source code.
Read files to understand an existing project.
Explore project structures.

3. File Management

Enable agents to:

Create project directories.
Generate new files.
Update existing files.
Organize development workflows.

4. Development Automation

Combine shell commands, Python execution, and file operations to automate repetitive programming tasks.

5. Local AI Agents

Connect local LLMs to MCP tools through frameworks such as LangChain, without requiring a hosted LLM API for inference.

⚙️ How It Works

              User Request
                   |
                   v
              AI Agent (LLM)
                   |
                   v
                MCP Client
                   |
                   v
        Agentic Terminal MCP Server
                   |
          +--------+--------+
          |        |        |
          v        v        v
         Bash    Python   File Tools
          |        |        |
          +--------+--------+
                   |
                   v
             Tool Results
                   |
                   v
              AI Agent

The LLM determines which tools to call based on the task. The MCP server exposes the available capabilities and returns tool results to the client.

🛠️ Technology Stack

Python
Model Context Protocol (MCP)
FastMCP
LangChain integration
Ollama-compatible local LLM workflows

⚠️ Important Notes

This package provides tools to AI applications; it does not include or host an LLM.
An MCP-compatible client is required to interact with the server.
Shell commands and file operations run in the environment where the MCP server executes.
AI-generated code and command results should be reviewed and tested.
Use an appropriately controlled environment when allowing an agent to execute commands or modify files.

🔗 Links

PyPI: https://pypi.org/project/mohamed-agentic-terminal/
Model Context Protocol: https://modelcontextprotocol.io/
uv Documentation: https://docs.astral.sh/uv/
Ollama: https://ollama.com/

📄 License

See the project repository for license information.

MCP Gateway

A Dockerized gateway that connects multiple MCP servers through one Streamable HTTP endpoint.

Architecture

DuckDuckGo MCP Server
Agentic Terminal MCP Server
Streamable HTTP transport

Run with Docker

Pull the image:

docker pull mmahmoud15901/mcp-gateway:0.1.2

Run the Gateway locally:

docker run -d --name mcp-gateway -p 127.0.0.1:8001:8001 mmahmoud15901/mcp-gateway:0.1.2

View logs:

docker logs -f mcp-gateway

MCP Endpoint

http://127.0.0.1:8001/mcp

Use Streamable HTTP transport.

Security

The Agentic Terminal server can execute shell commands and Python code and modify files. Keep the Gateway bound to localhost. Do not expose it publicly without authentication and access controls.

Never commit credentials or .env files.

Docker Image

https://hub.docker.com/r/mmahmoud15901/mcp-gateway

Image tag: 0.1.2

Available Tools

9 tools

bashC

This function will execute a bash command and return the output. This function is useful for executing bash commands including creating files, directories, and other bash commands.

Name	Required	Description	Default
`command`	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 carries the full burden of behavioral disclosure. It mentions creating files and directories, but omits that bash can modify, delete, or affect the system in unintended ways. No working directory, permissions, or error handling details are disclosed.

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 at two sentences and front-loads the core action in the first sentence. The second sentence adds redundant phrasing ('other bash commands') but does not significantly impede understanding.

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 executes arbitrary bash commands, the description lacks important context such as return format, error behavior, environment, and side-effect warnings. The absence of an output schema and annotations makes this a substantial gap.

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's only parameter 'command' has no description, and the tool description merely echoes 'bash command' without explaining syntax, examples, or constraints. With 0% schema description coverage, this fails to compensate for the missing parameter semantics.

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 tool 'will execute a bash command and return the output', specifying the verb 'execute' and the resource 'bash command'. It distinguishes bash from siblings like python_code and write_file, though it does not explicitly contrast with them.

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?

There is no guidance on when to use bash versus alternatives such as python_code, write_file, or create_folder. The phrase 'useful for executing bash commands including creating files, directories' offers examples but no selection criteria, exclusions, or context.

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

create_folderB

This function will create a folder with the given name. If the folder already exists, it will return a message indicating that the folder already exists.

Name	Required	Description	Default
`folder`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the burden of disclosure. It mentions the key behavior of returning a message if the folder already exists, which is useful. However, it does not disclose other relevant behaviors such as whether parent directories are created, error handling, or permission requirements.

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 sentence that efficiently conveys the core function and a conditional behavior. It is front-loaded and contains no filler or redundant wording.

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 one parameter and no annotations/output schema, the description covers the basic operation but omits important operational details such as path resolution, error behavior, and return types. It also does not indicate when this tool should be preferred over sibling tools, making it adequate but incomplete.

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 only parameter 'folder' has no schema description, and the description only refers to 'the given name,' adding little beyond the schema's name and type. It does not clarify whether this should be a full path, relative path, or just a folder name, leaving important ambiguity.

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 creates a folder with a given name and adds the idempotency behavior (returns a message if the folder exists). This is specific and distinguishes it from siblings like delete_folder 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 Guidelines1/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 like bash (which could use mkdir) or python_file. There is no mention of prerequisites, path handling, or exclusions.

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

delete_folderA

This function will delete a folder with the given name. If the folder does not exist, it will return a message indicating that the folder does not exist.

Name	Required	Description	Default
`folder`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only mentions behavior when the folder does not exist, missing success behavior, permission requirements, or whether deletion is recursive. This is minimal coverage.

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 two sentences, front-loaded with the main action, and includes a conditional edge case. Every sentence earns its place with no fluff.

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 one parameter and no output schema, the description covers the core action and one edge case. However, it omits return behavior on success and any side effects, making it only minimally 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?

The schema has one parameter 'folder' with no description (0% coverage). The description clarifies that the parameter is the folder's name ('with the given name'), adding some meaning beyond the schema. However, it does not provide format or validation 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 deletes a folder by name, using the specific verb 'delete' and resource 'folder'. It distinguishes from siblings like create_folder by its destructive action.

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 by stating its function, but does not explicitly mention when to prefer this tool over alternatives or any conditions (e.g., safety checks, prerequisites). It provides clear context but no exclusions or alternative references.

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

globB

This function will return a list of files that match the given pattern. This function is useful for finding files in a directory.

Name	Required	Description	Default
`pattern`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states that a list of files is returned, but does not mention recursion, pattern syntax, hidden files, error handling, or the read-only nature. This is a significant transparency gap for a tool that lacks annotation support.

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 the core purpose in the first sentence. However, the second sentence ('This function is useful for finding files in a directory') is somewhat redundant and could be removed, but it is not excessively verbose.

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

Completeness2/5

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

For a tool with no annotations and no output schema, the description is too sparse. It fails to cover glob syntax, pattern examples, return behavior (e.g., empty list on no match), and any limitations. A simple tool still benefits from a few more details to be complete enough for an AI agent to use 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?

The schema_description_coverage is 0% and the description does not compensate. The only parameter 'pattern' is referred to as 'the given pattern' without explaining that it is a glob pattern, its syntax, or examples. The description adds no useful semantic value beyond the schema's field name.

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 function: returning a list of files that match a given pattern. It also mentions 'finding files in a directory', which distinguishes it from sibling tools like grep (content search) or read_file (file access).

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 statement 'useful for finding files in a directory' provides some context but does not explicitly mention alternatives or when not to use this tool. It does not name grep or bash as alternatives, so it falls short of explicit usage guidance.

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

grepB

This function will search for the given pattern in the specified file and return the matching lines.

Name	Required	Description	Default
`file`	Yes
`pattern`	Yes

TDQS

B3.1/5.0

Behavior3/5

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

With no annotations, the description must carry the full burden of behavioral disclosure. It states the core behavior (search and return matching lines) but does not mention potential details like regex handling, case sensitivity, or error behavior, leaving moderate gaps.

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 front-loads the action and directly states purpose. There is no redundant information or filler, making it 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 tool is simple, but with no annotations, no output schema, and no parameter descriptions, the description is somewhat thin. It covers the main function but omits details like return format and edge cases, leaving the agent with unanswered questions.

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%, so the description must compensate by explaining the parameters. It only names 'pattern' and 'specified file' in a generic way, adding little meaning beyond the schema's property names. The description does not clarify pattern syntax or file path format.

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 tool searches for a pattern in a file and returns matching lines, which identifies the verb, resource, and result. However, it does not explicitly distinguish itself from siblings like bash or read_file, so it falls short of a perfect score.

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?

There is no guidance on when to use this tool versus alternatives such as bash, read_file, or glob. No context is given about suitable scenarios or exclusions, leaving the agent to infer usage from the tool name alone.

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

python_codeB

This function will execute a python code and return the output.

Name	Required	Description	Default
`code`	Yes

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 carries the full burden for behavioral disclosure. It only mentions execution and returning output, omitting details about side effects, execution environment, error handling, or whether the output is stdout, stderr, or an exit code.

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, front-loaded sentence with no unnecessary words. It efficiently states the core action and result, making it appropriately concise.

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

Completeness2/5

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

Given the lack of annotations, output schema, and the inherent complexity of a code execution tool, the description is insufficient. The agent is not informed about the output shape, potential side effects, or safety considerations, leaving significant gaps.

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

Parameters4/5

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

The input schema has one 'code' parameter with no description, and the description clarifies that it represents the Python code to execute. This adds meaning beyond the schema, but does not provide constraints like size or format specifics.

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 the tool executes Python code and returns output, using a specific verb and resource. However, it does not differentiate from sibling tools like python_file or bash, so it falls short of a perfect score.

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

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as bash or python_file. It lacks any context about preferred use cases or exclusions.

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

python_fileB

This function will execute a python file and return the output.

Name	Required	Description	Default
`file`	Yes

TDQS

B3.1/5.0

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 disclosing behavior. It only says it executes and returns output, but does not explain how errors are handled, what 'output' includes (stdout, stderr, exit code), whether execution is synchronous, or any side effects. This is a significant gap for a code execution 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 a single sentence that is concise and front-loaded with the core action. There is no wasted wording or redundant information. It is appropriately sized for a simple one-parameter tool.

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 no annotations and no output schema, the description should provide more operational context. It omits critical details like error behavior, return format, and environment requirements. While the tool is simple, the lack of behavioral disclosure makes it incomplete for an AI agent to invoke safely and correctly.

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 'file' parameter beyond its name. It does not state whether 'file' is a path, content, or how paths are resolved. The description adds no meaningful param detail beyond what the schema already implies.

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: 'execute a python file and return the output.' It uses a specific verb ('execute') and resource ('python file'), and it differentiates from sibling tools like python_code (which likely runs code snippets) and bash (which runs shell commands) by focusing on file execution.

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

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., Python installed), when choosing it over python_code or bash, or any exclusions. There is no explicit '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.

read_fileB

This function will read the contents of a file and return it as a string.

Name	Required	Description	Default
`file`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description must carry the full burden. It merely restates the tool's name and basic action without disclosing error behavior, encoding handling, or safety properties. The description adds minimal value beyond the tool name itself.

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 is front-loaded and directly states the action and return type. Every word is necessary and there is no redundancy.

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 read tool with no output schema, the description does explain the return type (string). However, it lacks detail on edge cases like missing files, permission errors, or path interpretation, which an agent may need. It is adequate but not comprehensive.

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 only parameter 'file' has 0% schema description coverage, and the description does not specify whether it expects a path, URI, or file name. The description provides no additional meaning to the parameter beyond its name, leaving the agent to guess.

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 reads a file's contents and returns them as a string, which is a specific verb-resource pair. It distinguishes itself from siblings like write_file (write), grep (search), and glob (list files by pattern).

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 usage is implied: use when you need the full contents of a file. However, there is no explicit guidance on when not to use it or mention of alternatives like grep for searching, so it does not fully differentiate from sibling tools.

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

write_fileA

This function will write the given content to a file. If the file does not exist, it will be created.

Name	Required	Description	Default
`file`	Yes
`content`	Yes

TDQS

A3.8/5.0

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. It discloses the auto-create behavior ('If the file does not exist, it will be created'), which is valuable. However, it does not mention whether existing files are overwritten or appended, nor any path or permission requirements.

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 sentence that is direct and front-loaded, stating the primary function and the key creation behavior. 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?

While the tool is simple and the description covers the main purpose, it lacks important details such as overwrite behavior and path handling. Given no annotations and no output schema, the description is minimally viable but not fully complete.

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%, so the description must compensate. It only vaguely maps 'given content' to the content parameter and 'to a file' to the file parameter. No details are given about path formats, expected content type, or behavior for special paths.

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 writes content to a file, using the specific verb 'write' and resource 'file'. It also mentions creation if the file does not exist, which distinguishes it from read_file and other file-related siblings.

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 implies when to use the tool (to write or create files) and the context is clear given sibling tools like read_file and create_folder. However, it does not explicitly mention when not to use it or name alternatives, so it falls slightly short of a 5.

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.

9 tool updatesv1.0.0Oct 29, 2026
- First observedbash
- First observedcreate_folder
- First observeddelete_folder
- First observedglob
- First observedgrep
- First observedpython_code
- First observedpython_file
- First observedread_file
- First observedwrite_file

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-10-29 04:55 across 9 tools

Disambiguation3/5

Most tools are individually understandable, but bash is a catch-all that overlaps with read_file, write_file, create_folder, delete_folder, glob, grep, and Python execution. python_code and python_file are also closely related, so an agent may hesitate between shell, Python-string, and Python-file execution paths.

Naming Consistency3/5

The set mixes verb_noun names like read_file, write_file, create_folder, and delete_folder with noun-only names like bash, glob, and grep, plus python_code and python_file. It remains readable, but there is no single predictable naming convention.

Tool Count5/5

Nine tools is a well-scoped set for a terminal/file-manipulation server. Each tool maps to a common operation, and the count is comfortably within the typical 3-15 range.

Completeness4/5

The surface covers command execution, Python execution, file reading/writing, globbing, grepping, and folder creation/deletion. Minor gaps exist for direct file deletion or moving/copying files, but bash can handle those operations.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5365
https://api.gread.dev/mcp
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
https://mcp.niftypm.com/mcp
Node Command
io.github.huseyincig
Remote MCP server exposing your Node Command fleet (files, shell, processes, browser) to AI hosts.
File Systems Shell Access Browser Automation
1
https://mcp.nodecommand.app/mcp
Substrate B
co.trysubstrate
Shared memory MCP server for Claude Code, Codex, Gemini CLI and Cursor. Cited, editable.
Developer Tools Knowledge & Memory
131
https://app.trysubstrate.co/mcp

Related MCP Servers

GPT Commander
File Systems Shell Access Developer Tools
PushPullCommitPush
A
license
C
quality
C
maintenance
A security-first MCP server that provides LLMs with structured tools for filesystem, process, search, build/test/lint, IDE integration, and more.
Updated 10 months ago (2026-01-11 08:47 UTC)
40
2
PolyForm Noncommercial 1.0.0
Shell Server
Shell Access Command Line
schajii
F
license
A
quality
D
maintenance
A simple MCP server that exposes a terminal tool, allowing AI agents to execute shell commands.
Updated 4 months ago (2026-06-30 10:04 UTC)
1
-
Smart Terminal MCP
Shell Access File Systems Code Execution
BilalCodePhoenix
F
license
B
quality
C
maintenance
A lightweight MCP server that enables AI assistants to interact with the local machine through terminal, filesystem, and Python execution tools.
Updated 17 days ago (2026-10-19 07:14 UTC)
9
-
dev-mcp
CodeIbrah
A
license
Not graded
quality
D
maintenance
A local MCP server that gives AI agents access to developer tooling — GitHub (read-only), documentation search, and web research — via stdio transport.
Updated 3 months ago (2026-07-27 12:11 UTC)
MIT

Mohamed Agentic Terminal

✨ Features

📦 Installation

Option 1: Run with uvx

Option 2: Install in a Python project

🔌 Connect to an MCP Client

🤖 Usage with LangChain and Ollama

Step 1: Create a project

Step 2: Install and prepare Ollama

Step 3: Create agent.py

Step 4: Run the agent

💡 Use Cases

1. AI Coding Assistants

2. Codebase Exploration

3. File Management

4. Development Automation

5. Local AI Agents

⚙️ How It Works

🛠️ Technology Stack

⚠️ Important Notes

🔗 Links

📄 License

See the project repository for license information.

MCP Gateway

Architecture

Run with Docker

MCP Endpoint

Security

Docker Image

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Option 1: Run with `uvx`

Step 3: Create `agent.py`