Skip to main content
Glama

workspace_edit_file

Destructive

Replace one exact text occurrence in a workspace file, or every occurrence with replace_all=true; surrounding text and line endings stay unchanged.

Instructions

Replace one exact text occurrence, or all with replace_all=true.

old_text must be nonempty. Missing or ambiguous matches leave the file unchanged. Text and line endings outside replacements are preserved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
new_textYes
old_textYes
replace_allNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
resourcesNo
replacementsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the write profile is covered. The description adds genuine behavioral context beyond that: missing or ambiguous matches leave the file unchanged (safety on failure), and text/line endings outside replacements are preserved (scope of mutation). It stops short of noting permission or concurrency 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?

Three tight sentences with zero filler, and the core behavior (one occurrence, or all) is front-loaded in the first line. Every sentence adds a distinct fact: replacement scope, failure behavior, preservation guarantee.

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 an output schema present, return values need no explanation, and the description covers mutation scope, failure behavior, and preservation of surrounding content. An agent has what it needs to call this safely; only the sibling-routing and permission story are missing.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry the load. It explains old_text (must be nonempty) and replace_all (single vs. all occurrences), which are the two parameters whose semantics aren't self-evident. Only path and new_text go unexplained, and both are obvious from their names.

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?

States a specific verb and resource: replace one exact text occurrence, or all occurrences when replace_all=true. This is clearly distinguishable from a full-file write, though it never names workspace_write_file as the alternative. The purpose is unambiguous without opening the schema.

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?

Usage is implied by 'replace one exact text occurrence' versus replace_all=true, which tells the agent which mode to pick. However, there is no explicit guidance on when to prefer this over workspace_write_file, nor any exclusions for when editing is inappropriate.

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