Skip to main content
Glama

file_ops

Perform file-system operations such as reading, writing, editing, moving, copying, hashing, compressing, and checking files, with concurrency-safe atomic writes to prevent corruption.

Instructions

Comprehensive file system operations with concurrency-safe writes.

Operations: read_file, write_file, edit_file, delete_file, move_file, copy_file, read_file_lines, read_multiple_files, file_exists, get_file_info, head_file, tail_file, undo_edit, get_file_hash, append_file, touch_file, compress, decompress.

Line indexing: read_file_lines offset is a 0-based line index (0 = first line of the file). The response echoes offset/limit plus first_line_number (1-based number of the first returned line, null when empty) so callers can chain pages via next_steps without guessing.

Write operations (write_file, edit_file, move_file, copy_file) use per-path asyncio.Lock + atomic os.replace() to prevent corruption under concurrent access.

Args: See Parameters block.

Return Format

{"success": bool, "action": str, "message": str, "result": {...}}

  • success: whether the operation succeeded

  • action: the operation performed (e.g. "read_file")

  • message: natural-language summary for the user

  • result: operation-specific payload (file content, info dict, moved path, etc.) On failure, returns {"success": false, "error": str, "error_type": str, "suggestions": [...]}.

Examples

file_ops(operation="read_file", path="C:/Users/me/notes.md") file_ops(operation="write_file", path="D:/data/out.txt", content="hello") file_ops(operation="edit_file", path="D:/data/app.py", old_string="foo", new_string="bar") file_ops(operation="copy_file", path="a.txt", destination_path="b.txt")

Input Schema

NameRequiredDescriptionDefault
pathNo
limitNo
linesNo
offsetNo
contentNo
new_strNo
old_strNo
encodingNoutf-8
is_regexNo
no_backupNo
operationNo
overwriteNo
check_typeNofile
file_pathsNo
new_stringNo
old_stringNo
replace_allNo
replacementsNo
allow_multipleNo
archive_formatNozip
create_parentsNo
ensure_newlineNo
hash_algorithmNosha256
follow_symlinksNo
include_contentNo
destination_pathNo
max_content_sizeNo
max_file_size_mbNo
ignore_whitespaceNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.1.0

TDQS

C2.5/5.0
Behavior1/5

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

The description includes delete_file among supported operations while annotations declare destructiveHint=false, a direct contradiction of the destructive safety signal. Although concurrency-safe writes and return/failure shapes add useful context, the annotation contradiction caps this dimension.

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?

It is well structured, front-loading operations and then covering line indexing, write safety, return format, and examples. The phrase 'Args: See Parameters block' is wasted, and the return-format section partly duplicates the output schema, but overall it is efficient for such a large 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?

For a 29-parameter multi-operation tool with no schema parameter descriptions, the definition omits operation-specific parameter requirements and destructive/backup behavior. The output schema and return-format section help, but they do not compensate for the missing operational detail.

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% for 29 parameters, yet the description explains only offset/limit line indexing and a few examples. It leaves most parameters, including content, overwrite, no_backup, and the ambiguous old_str/new_str versus old_string/new_string fields, undefined.

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 resource and enumerates the 18 file operations, so the tool's scope is clear. It does not, however, distinguish this from siblings like dir_ops or search_ops.

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?

It lists operations and examples but gives no explicit when-to-use/when-not guidance or routing against sibling tools such as dir_ops and search_ops. Selection between operations is left entirely to inference.

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