How do I use agent-godmode?

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., "@agent-godmode list all Python files in the project" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

agent-godmode

by mdvohra

Overview Schema Related Servers Score Discussions

Python

Local

agent-godmode

Workspace-scoped MCP tools for building Cursor-style agents: read_file, write_file, edit_file, run_command, list_files. Includes strict, versioned system prompts (SYSTEM_PROMPT_V1) and OpenAI-style tool definitions so your app can wire any LLM with one import.

The LLM and API keys stay in your app. This package provides tool execution, sandboxing, and prompts—not a hosted model.

OpenAI + in-process tools: the Tier B section below is self-contained—copy the Python into a script, module, or REPL; no separate artifact is required.

Install

pip install agent-godmode

Editable / dev:

pip install -e ".[dev]"

Migrating from mcp-agent-tools: uninstall the old package, install agent-godmode, change Python imports from mcp_agent_tools to agent_godmode, the CLI from mcp-agent-tools to agent-godmode, and environment variables from MCP_AGENT_TOOLS_* to AGENT_GODMODE_* (for example AGENT_GODMODE_ROOT).

Related MCP server: SkyDeckAI Code

Tools

All tools are scoped to a single workspace root. Paths are relative to that root (or absolute only if they resolve under it). The same operations are available over MCP (the agent-godmode server) and in-process via AgentWorkspace / WorkspaceTools.

Tool	Purpose
`read_file`	Read a UTF-8 text file; optional line range and byte cap.
`write_file`	Create or overwrite/append UTF-8 text; creates parent directories.
`edit_file`	Search-and-replace in an existing UTF-8 file: non-empty `old_string`, optional `replace_all`. With `replace_all=false`, `old_string` must match exactly once (use surrounding context from `read_file` for uniqueness). Invalid UTF-8 returns an error instead of corrupting binary data.
`list_files`	List directory entries with optional recursion, glob, depth cap, dotfile control.
`run_command`	Run a subprocess from an `argv` list only (no shell); optional `cwd` under the root.

For LLM integrations, tool shapes and descriptions are centralized in OPENAI_TOOL_DEFINITIONS and TOOL_DESCRIPTIONS; agent behavior is guided by SYSTEM_PROMPT_V1.

Tier A — Cursor (or any MCP client)

1. Pick a workspace directory (only paths under this root are allowed).

2. Add a server entry (stdio). Example for a global MCP config (paths use forward slashes on Windows):

{
  "mcpServers": {
    "agent-godmode": {
      "command": "agent-godmode",
      "args": [],
      "env": {
        "AGENT_GODMODE_ROOT": "D:/your/project"
      }
    }
  }
}

Or with an explicit CLI root (overrides env for that process):

{
  "mcpServers": {
    "agent-godmode": {
      "command": "agent-godmode",
      "args": ["--root", "D:/your/project"]
    }
  }
}

3. Paste SYSTEM_PROMPT_V1 (from agent_godmode.prompts or below) into your host’s system prompt if the client does not load server instructions automatically.

Environment variables

Variable	Meaning
`AGENT_GODMODE_ROOT`	Required unless `--root` is passed. Absolute workspace root.
`AGENT_GODMODE_MAX_READ_BYTES`	Max bytes per read (default `512000`).
`AGENT_GODMODE_COMMAND_TIMEOUT`	Subprocess timeout in seconds (default `120`).
`AGENT_GODMODE_MAX_COMMAND_OUTPUT_BYTES`	Truncate stdout/stderr combined (default `256000`).
`AGENT_GODMODE_LIST_MAX_ENTRIES`	Cap for list_files (default `2000`).
`AGENT_GODMODE_ALLOWED_COMMANDS`	Comma-separated basenames allowed as `argv[0]` (e.g. `python,uv,node`). If unset, all commands allowed under the sandbox.

Tier B — Python app (in-process + OpenAI)

Design notes

Workspace root — Examples use D:\Avi-assign as a placeholder; point WORK_DIR at any directory you control.
API key policy — OPENAI_API_KEY is required only for Chat Completions. Imports set client = OpenAI() if HAS_OPENAI_KEY else None; workspace setup and direct edit_file run without a key.
Model-authored I/O — For write_file, persist only text returned by the model. For edit_file, the model must copy old_string exactly from read_file (see SYSTEM_PROMPT_V1).

1. Install dependencies

In a shell or any interactive Python session:

pip install -q openai
pip install -q -e "D:/MCP"   # editable checkout; or: pip install agent-godmode

If your environment supports line magics (for example %pip in IPython), you can run the same installs there; do not place shell comments on the same line as %pip.

2. Imports and API key handling

import os
from pathlib import Path

# OPENAI_API_KEY is required only for steps that call Chat Completions (LLM + agent loops).
# Workspace + direct edit_file work without a key.
# Set via OS env or e.g. %env OPENAI_API_KEY sk-... in IPython
# Local-only optional override — never commit a real key:
# os.environ["OPENAI_API_KEY"] = "sk-..."

from openai import OpenAI

from agent_godmode import (
    AgentWorkspace,
    OPENAI_TOOL_DEFINITIONS,
    SYSTEM_PROMPT_V1,
    run_agent_loop,
)

HAS_OPENAI_KEY = bool(os.environ.get("OPENAI_API_KEY"))
client = OpenAI() if HAS_OPENAI_KEY else None
MODEL = "gpt-4o-mini"

if not HAS_OPENAI_KEY:
    print(
        "Note: OPENAI_API_KEY not set — Chat Completions examples will raise until you set it. "
        "Workspace + direct edit_file still work."
    )

3. Workspace bootstrap and seed file

# Fixed workspace — all reads/writes/commands stay under this folder
WORK_DIR = Path(r"D:\Avi-assign")
WORK_DIR.mkdir(parents=True, exist_ok=True)
print("Workspace:", WORK_DIR.resolve())

hello = WORK_DIR / "hello.txt"
if not hello.exists():
    hello.write_text("Hello from Avi-assign workspace.\n", encoding="utf-8")

ws = AgentWorkspace(WORK_DIR)
print(ws.read_file("hello.txt"))
print("--- list_files ---")
print(ws.list_files(".", recursive=False))

4. LLM-authored file body (no tool calls)

Requires OPENAI_API_KEY. Skip if you are only exercising tools without the API.

if client is None:
    raise ValueError(
        "Set OPENAI_API_KEY to run this block (e.g. export OPENAI_API_KEY=... or %env in IPython). "
        "Skip if you only want workspace / edit_file demos."
    )

# 1) Context from disk (read-only)
context = ws.read_file("hello.txt")

# 2) Ask the model to author the entire new file; no static template for the body
user_prompt = (
    "Here is the current contents of hello.txt in my workspace:\n\n"
    f"---\n{context}\n---\n\n"
    "Write ONLY the body of a new Markdown file (no preamble, no code fences) "
    "with a title line and two bullet points explaining what this greeting is for."
)

resp = client.chat.completions.create(
    model=MODEL,
    messages=[
        {
            "role": "system",
            "content": "You output only the file body the user asked for. No extra commentary.",
        },
        {"role": "user", "content": user_prompt},
    ],
)

generated = (resp.choices[0].message.content or "").strip()
if not generated:
    raise RuntimeError("LLM returned empty content; nothing to write.")

# 3) Persist exactly what the LLM produced
out_rel = "llm_generated_notes.md"
ws.write_file(out_rel, generated, mode="overwrite")
print(f"Wrote {out_rel!r} ({len(generated)} chars from model)\n")
print(ws.read_file(out_rel))

5. Direct `edit_file` (no Chat Completions)

No API key required. The next lines create ws if you have not run the workspace section yet (same root).

# Direct edit_file (no Chat Completions call).
# If `ws` is not defined yet (e.g. you skipped §3), the next few lines create it (same WORK_DIR).
from pathlib import Path

from agent_godmode import AgentWorkspace

if "ws" not in globals():
    WORK_DIR = Path(r"D:\Avi-assign")
    WORK_DIR.mkdir(parents=True, exist_ok=True)
    ws = AgentWorkspace(WORK_DIR)

demo_edit = "edit_demo.txt"
ws.write_file(
    demo_edit,
    "version: 1\nstatus: draft\nfooter: end\n",
    mode="overwrite",
)
print("--- before ---")
print(ws.read_file(demo_edit), end="")
print(ws.edit_file(demo_edit, old_string="status: draft", new_string="status: ready"))
print("--- after ---")
print(ws.read_file(demo_edit), end="")

6. Agent loop: model calls `write_file`

Requires OPENAI_API_KEY.

if client is None:
    raise ValueError(
        "Set OPENAI_API_KEY to run this block. "
        "Skip if you only need workspace or direct edit_file."
    )


def complete(messages, tools):
    """One Chat Completions turn; return OpenAI-shaped dict for run_agent_loop."""
    resp = client.chat.completions.create(
        model=MODEL,
        messages=messages,
        tools=tools,
        tool_choice="auto",
    )
    return resp.model_dump()


answer = run_agent_loop(
    complete,
    "Use tools only. List the workspace root, read hello.txt, then call write_file on "
    "agent_notes.txt. The `content` argument must be your own freshly written summary "
    "(several sentences) based only on what you read—do not paste boilerplate.",
    ws,
    system_prompt=SYSTEM_PROMPT_V1,
    max_turns=12,
)
print("--- final answer ---")
print(answer)
print("--- agent_notes.txt (if created by tool write_file) ---")
p = WORK_DIR / "agent_notes.txt"
print(p.read_text(encoding="utf-8") if p.exists() else "(missing)")

7. Agent loop: model calls `edit_file`

Requires OPENAI_API_KEY and the complete function from §6.

from pathlib import Path

from agent_godmode import AgentWorkspace

if "ws" not in globals():
    WORK_DIR = Path(r"D:\Avi-assign")
    WORK_DIR.mkdir(parents=True, exist_ok=True)
    ws = AgentWorkspace(WORK_DIR)
if "complete" not in globals():
    raise NameError("Define `complete` in §6 (after imports) before running this block.")
if client is None:
    raise ValueError(
        "Set OPENAI_API_KEY to run this block. "
        "The direct edit_file example in §5 works without a key."
    )

target = "edit_agent_target.txt"
ws.write_file(
    target,
    "# Demo\nThere are three erorrs in this sentance.\n",
    mode="overwrite",
)
edit_answer = run_agent_loop(
    complete,
    (
        f"Use tools only. Read `{target}`. Then use edit_file (not write_file) to fix typos: "
        "change erorrs to errors and sentance to sentence. "
        "Copy old_string exactly from read_file; use two edit_file calls or replace_all where appropriate."
    ),
    ws,
    system_prompt=SYSTEM_PROMPT_V1,
    max_turns=14,
)
print("--- agent (edit_file) answer ---")
print(edit_answer)
print("--- file after agent ---")
print(ws.read_file(target), end="")

8. Optional: custom tool loop without `run_agent_loop`

Use OPENAI_TOOL_DEFINITIONS, call the Chat Completions API with tools=..., parse tool_calls, and route each call through ws.dispatch(name, json.loads(arguments)) (requires import json). For write_file, the content field should be whatever the model authored; for edit_file, pass old_string, new_string, and replace_all exactly as the model returned.

Optional limits on `AgentWorkspace`

ws = AgentWorkspace(
    r"D:\Avi-assign",
    allowed_commands=frozenset({"python", "uv"}),
    command_timeout_sec=60.0,
)

Lower-level (`WorkspaceTools` + `OPENAI_TOOL_DEFINITIONS`)

Same sandbox without AgentWorkspace: use config_from_root(...) and WorkspaceTools. Pass OPENAI_TOOL_DEFINITIONS to your provider as tools= when you implement your own loop instead of run_agent_loop.

from agent_godmode import WorkspaceTools, OPENAI_TOOL_DEFINITIONS, SYSTEM_PROMPT_V1
from agent_godmode.config import config_from_root

tools = WorkspaceTools(config_from_root(r"D:\Avi-assign"))
print(tools.read_file("hello.txt"))

Compose the system message:

final_system = SYSTEM_PROMPT_V1 + "\n\n" + "Your org rules here."

Imports reference

AgentWorkspace — pass a directory path; use read_file / write_file / edit_file / list_files / run_command on that tree only
SYSTEM_PROMPT_V1, SYSTEM_PROMPT_CHANGELOG, TOOL_DESCRIPTIONS
OPENAI_TOOL_DEFINITIONS — same shapes as MCP tools (for tools= in chat completions)
build_server(config) — build a FastMCP app (stdio via build_server(cfg).run())
run_agent_loop — minimal multi-turn executor with your complete callable (accepts WorkspaceConfig or AgentWorkspace)

Safety model

Python: all paths are resolved under the directory you passed to AgentWorkspace(...) or config_from_root(...).
MCP / CLI: same rule via AGENT_GODMODE_ROOT or --root (no .. escape).
read_file, write_file, and edit_file only touch UTF-8 text paths under that root; edit_file requires valid UTF-8 (strict decode).
run_command uses argv only (no shell). Optional allowlist via AGENT_GODMODE_ALLOWED_COMMANDS.
Subprocess inherits the current environment; avoid passing secrets you do not want child processes to see.

CLI

agent-godmode --root D:/your/project

Runs the MCP server on stdio (default for Cursor).

Agent loop (conceptual)

System = SYSTEM_PROMPT_V1 (+ optional suffix).
User message + OPENAI_TOOL_DEFINITIONS → your LLM.
For each tool_call, run WorkspaceTools.dispatch (or MCP call_tool) — including read_file, write_file, edit_file, list_files, and run_command as defined by the server.
Append tool results; repeat until the model returns text without tools.

run_agent_loop implements steps 2–4 given your complete() function.

License

MIT

MCP Badge

Available Tools

5 tools

edit_fileA

Search-and-replace in an existing UTF-8 file: old_string must be non-empty and match exactly once unless replace_all is true. Read the file first and copy the exact span. Output uses newline='\n' like write_file.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`new_string`	Yes
`old_string`	Yes
`replace_all`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses UTF-8 handling, newline convention, and match constraints (exact, unique unless replace_all). However, it omits permissions, error handling, and whether the file is created if missing.

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

Conciseness5/5

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

Two sentences with no redundancy. Every word is informative. Front-loaded with the core operation and key constraints.

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 an output schema exists, the description covers operation, constraints, and a usage hint. It mentions UTF-8 and newline convention. Could add error handling or file existence requirement, but overall adequate for a well-defined edit tool.

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 has 0% description coverage, so the description compensates partially. It explains old_string (non-empty, exact match) and replace_all (changes behavior). Path and new_string are implied but not detailed. Adds moderate value beyond names.

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 it performs search-and-replace on an existing UTF-8 file, which distinguishes it from siblings like read_file, write_file, and run_command. It specifies the action and resource concisely.

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 explicit guidance: 'Read the file first and copy the exact span.' It also clarifies conditions (old_string must match exactly once unless replace_all is true). However, it does not explicitly contrast with write_file for full rewrites.

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

list_filesA

List files and directories under a workspace path. Optional recursive, glob_pattern, max_depth, include_dotfiles. Use to discover layout before reading.

ParametersJSON Schema

Name	Required	Default
`path`	No	.
`max_depth`	No
`recursive`	No
`glob_pattern`	No
`include_dotfiles`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries burden. It describes listing behavior and optional parameters but doesn't disclose details like performance, permissions, or output format. Adequate but minimal.

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

Conciseness5/5

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

Two sentences, front-loaded with action, no wasted words. Every sentence adds value.

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

Completeness4/5

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

For a simple list tool with output schema, description is mostly complete. It mentions optional parameters and usage context. Could note sorting or limits, but overall sufficient.

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%, so description must compensate. It lists parameter names (recursive, glob_pattern, max_depth, include_dotfiles) but doesn't explain their semantics beyond names. Adds some value but insufficient detail.

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

Purpose5/5

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

Description clearly states verb 'List' and resource 'files and directories under a workspace path'. It distinguishes from sibling tools (read_file, write_file, etc.) by positioning itself as a discovery tool.

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

Usage Guidelines5/5

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

Explicitly states 'Use to discover layout before reading', providing clear context and guidance on when to use this tool relative to reading files.

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

read_fileA

Read a UTF-8 text file under the workspace. Use before editing when content is unknown. Optional start_line/end_line (1-based inclusive). Optional max_bytes override.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`end_line`	No
`max_bytes`	No
`start_line`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/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 specifies that the file is UTF-8 text, and mentions optional line range (1-based inclusive) and max_bytes override. It does not detail error handling or behavior for non-existent paths, but the core behavior is well communicated.

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 long, front-loading the purpose and file type, followed by usage guidelines and parameter details. Every sentence earns its place with no redundancy.

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

Completeness4/5

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

Given the tool is a simple file reader with an output schema (not shown), the description covers the main usage, line range, and byte limit. It is mostly complete but could mention error cases or binary file handling for full completeness.

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 schema coverage is 0%, so the description must add meaning. It does so by explaining all parameters: path (required), start_line/end_line (1-based inclusive), and max_bytes override. This adds significant value beyond the schema's type information.

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 a UTF-8 text file under the workspace' with a specific verb and resource. It distinguishes itself from siblings like write_file, edit_file, run_command, and list_files.

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

Usage Guidelines4/5

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

The description explicitly says 'Use before editing when content is unknown', providing clear context for when to use the tool. It does not include explicit exclusions or alternatives, but the guidance is sufficient.

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

run_commandA

Run a subprocess with argv list only (no shell). Optional cwd relative to workspace or absolute path under root. Use only when necessary; prefer read/list for inspection.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No
`argv`	Yes
`timeout_sec`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It mentions 'no shell' which is important for security, and cwd constraints. However, it lacks disclosure of potential side effects, output handling, or timeout behavior.

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

Conciseness5/5

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

The description is two sentences with no wasted words, front-loading the core action and usage guidance.

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?

With 3 parameters and no annotations, the description covers argv and cwd adequately. The timeout parameter is undocumented, but the presence of an output schema may compensate for return behavior. Overall, sufficient for command execution.

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%, so description must compensate. It adds meaning for argv (list only) and cwd (relative or absolute under root), but provides no information about the timeout parameter.

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 runs a subprocess with an argv list and no shell, and specifies cwd constraints. It distinguishes from sibling tools (read_file, list_files) by explicitly advising to prefer those for inspection.

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

Usage Guidelines5/5

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

The description explicitly says 'Use only when necessary; prefer read/list for inspection', providing clear when-to-use guidance and directing to alternatives.

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

write_fileA

Write or append UTF-8 text under the workspace. Mode: overwrite or append. Creates parent dirs. Do not use without reading first unless you are creating a new file or already hold exact contents.

ParametersJSON Schema

Name	Required	Default
`mode`	No	overwrite
`path`	Yes
`content`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses mode (overwrite/append) and that parent directories are created, but lacks details on error handling, file locking, atomicity, or encoding guarantees. Adequate but not comprehensive.

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

Conciseness5/5

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

Two sentences, no excess. Front-loaded with main action, then concise usage warning. Every word adds value.

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 3 params and output schema, the description covers key behavioral aspects (mode, dir creation, usage caution). Minor missing details like error conditions or concurrency behavior, but mostly complete.

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

Parameters3/5

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

Schema description coverage is 0%, so description must compensate. It adds meaning for mode (default and options), path (under workspace), and content (UTF-8). However, it lacks details on path constraints, content size limits, or format of mode enum. Partial compensation.

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 the verb (write/append), resource (UTF-8 text under workspace), and mode distinction. Differentiates from siblings like read_file and edit_file through the write/append and create parent dirs functionality.

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?

Explicitly warns not to use without reading first unless creating a new file or holding exact contents, providing clear when-to-use guidance. Could be improved by explicitly contrasting with edit_file, but still effective.

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.

5 tool updatesv0.1.9Jul 28, 2026
- First observededit_file
- First observedlist_files
- First observedread_file
- First observedrun_command
- First observedwrite_file

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool serves a distinct purpose: reading, writing, editing, listing files, and running commands. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to understand.

Tool Count5/5

5 tools is well-scoped for a file system and command execution toolset, covering essential operations without redundancy.

Completeness3/5

The toolset covers read, write, edit, list, and execute, but lacks a delete or rename tool, which are common file operations. This is a notable gap for a general-purpose server.

Maintenance

ActivityInactive

ResponsivenessNo issues

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

OrchaOAuth
io.github.westonhancock
Securely search and manage workspace context files for AI agents and teams.
Search File Systems Knowledge & Memory
1
AgentDrive A
sh.agentdrive
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Agent Orchestration Developer Tools
202
PriorifyOAuth
app.priorify
Agent-complete, permission-scoped product operations for Priorify workspaces.
Product Management
1
HexisOAuth
io.github.Bevel-Software
Git-backed platform for skills, tools, and context for AI agents
Agent Orchestration Developer Tools
184

Related MCP Servers

MCP Workspace Server
File Systems Shell Access Developer Tools
ShayYeffet
A
license
Not graded
quality
C
maintenance
Provides secure, sandboxed file system access for AI assistants to read, write, and manage project files with controlled command execution capabilities, all confined to a designated workspace directory.
Updated 9 months ago (2025-12-20 08:42 UTC)
MIT
SkyDeckAI Code
Developer Tools Code Analysis Code Execution
fastmcp-me
A
license
Not graded
quality
D
maintenance
Provides tools for AI-driven development workflows including file system operations, code analysis, code execution, web fetching, and search.
Updated a year ago (2025-10-19 13:33 UTC)
Apache 2.0
Coding Agent MCP Server
Coding Agents File Systems Command Line
Sukarth
A
license
B
quality
B
maintenance
Provides coding agent capabilities including file operations, terminal commands, search functionality, and utility operations.
Updated 2 months ago (2026-07-07 11:37 UTC)
27
13
5
MIT
Coding Tools MCP
Coding Agents File Systems Command Line
R-HUA
F
license
Not graded
quality
A
maintenance
Enables AI agents to develop within a local project workspace by reading and modifying files, running commands and tests, checking Git state, and persisting progress as history sessions that can be restored in later conversations.
Updated 16 days ago (2026-08-22 07:31 UTC)
-

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/mdvohra/agent-godmode'

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

agent-godmode

Install

Tools

Tier A — Cursor (or any MCP client)

Environment variables

Tier B — Python app (in-process + OpenAI)

1. Install dependencies

2. Imports and API key handling

3. Workspace bootstrap and seed file

4. LLM-authored file body (no tool calls)

5. Direct edit_file (no Chat Completions)

6. Agent loop: model calls write_file

7. Agent loop: model calls edit_file

8. Optional: custom tool loop without run_agent_loop

Optional limits on AgentWorkspace

Lower-level (WorkspaceTools + OPENAI_TOOL_DEFINITIONS)

Imports reference

Safety model

CLI

Agent loop (conceptual)

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

5. Direct `edit_file` (no Chat Completions)

6. Agent loop: model calls `write_file`

7. Agent loop: model calls `edit_file`

8. Optional: custom tool loop without `run_agent_loop`

Optional limits on `AgentWorkspace`

Lower-level (`WorkspaceTools` + `OPENAI_TOOL_DEFINITIONS`)