How do I use agentic_actions_mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agentic_actions_mcp list files in current directory" 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_actions_mcp

by codewithyasho

Overview Schema Related Servers Score Discussions

Python

Local

Agentic Actions

A Python implementation of agentic actions for the MCP protocol.

Related MCP server: Sentinel Core Agent

HOW TO USE THIS MCP PACKAGE?

EXAMPLE:


from langchain_mcp_adapters.client import MultiServerMCPClient
from langchain.agents import create_agent
import asyncio
import os


async def main():

    client = MultiServerMCPClient(

        {


            "agentic_actions_mcp": {
                "transport": "stdio",
                "command": "uvx",
                "args": ["agentic_terminal"]
            }


        }
    )

    tools = await client.get_tools()

    print("\nAvailable tools:")
    for tool in tools:
        print(tool.name)

    agent = create_agent(
        model="ollama:llama3.2:latest",
        tools=tools,
        system_prompt='''
        You are a helpful assistant.
        You have access to the tools that helps you to perform various File IO operations.
        you can manage files, read and write data, and perform other file-related tasks.
        ''',
    )

    response = await agent.ainvoke(
        {"messages": [
            {
                "role": "user",
                "content": "hii, what can you do for me?"
            }
        ]}
    )

    print("\n\nResponse:")
    print(response["messages"][-1].content)

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

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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. Dates show when Glama detected each change.

9 tool updatesv0.1.0Aug 4, 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

Install Server

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

TDQS

B3.3/5.0

Disambiguation5/5

Each tool has a distinct purpose: python_code, bash, and python_file are clearly separated by execution type; glob and grep handle search; read_file and write_file handle file I/O; create_folder and delete_folder handle directory operations. The descriptions make these boundaries explicit, so an agent can reliably disambiguate.

Naming Consistency3/5

The tool names mix conventions: some are bare commands (bash, glob, grep), some are noun phrases (python_code, python_file), and some follow a verb_noun pattern (read_file, write_file, create_folder, delete_folder). While all use lowercase with underscores, the inconsistency in structure makes the set less predictable.

Tool Count5/5

The server has 9 tools, which is a well-scoped size for a development utility. Each tool covers a separate need—execution, search, reading/writing files, and folder management—without unnecessary overlap or bloat.

Completeness3/5

The toolset provides execution, search, read/write, and folder lifecycle operations, but it lacks a delete_file tool. This is a notable gap: users can create and modify files but cannot remove them, which creates a dead end for file management workflows.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Frenchie A
io.github.Lab94
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI & Machine Learning Image & Video Processing Speech Processing
72
mcp
com.skopik
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Agent Orchestration Knowledge & Memory Search
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
uldl
sh.uldl
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
File Systems Cloud Storage Agent Orchestration
2

Related MCP Servers

mcp-remote-agent
File Systems Shell Access Command Line
knownothing20
A
license
Not graded
quality
B
maintenance
Enables AI agents to remotely read/write files and execute commands on Linux servers via MCP protocol.
Updated a month ago (2026-08-02 01:39 UTC)
4
MIT
Sentinel Core Agent
File Systems Web Scraping Search
bhuvanmdev
F
license
Not graded
quality
D
maintenance
Enables file system operations, web scraping, and AI-powered search through MCP tools for use by LLM agents.
Updated a year ago (2025-05-15 13:16 UTC)
1
-
ai-distiller-mcp
File Systems Developer Tools
axonempire
F
license
Not graded
quality
D
maintenance
Provides filesystem access to Claude via the MCP protocol, enabling local file operations through natural language.
Updated a year ago (2025-08-09 22:12 UTC)
-
maic-server-fs-mcp
File Systems Command Line
maicFir
A
license
A
quality
B
maintenance
Provides LLMs with local filesystem operations (read/write files, list directories) and command execution via MCP, enabling file management and task automation within AI clients.
Updated 3 months ago (2026-06-20 09:27 UTC)
7
15
ISC

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/codewithyasho/MCP_DEPLOYMENT'

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