Skip to main content
Glama
patchloom

Patchloom

Official
by patchloom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

append_file

Destructive

Append content to an existing file, inserting a line ending first when the file lacks one.

Instructions

Append content to an existing file. Inserts the file's line ending first when the file does not already end with one. Example: {"content":"#[test]\nfn new_test() {}\n","path":"tests/test.rs"}

Input Schema

NameRequiredDescriptionDefault
pathYes
contentYes
agent_presetNoWhen true, replace uses the agent preset: unique, require_change, fuzzy floor 0.90, allow_absent_old false. Off unless set.
expected_sha256NoSHA-256 hex of the file's current bytes. If it does not match, the tool returns error_kind stale and writes nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.32.6
    • addedInput schema / properties / agent_preset
      Added value: +{
+  "default": false,
+  "description": "When true, replace uses the agent preset: unique, require_change, fuzzy floor 0.90, allow_absent_old false. Off unless set.",
+  "type": "boolean"
+}
    • addedInput schema / properties / expected_sha256
      Added value: +{
+  "description": "SHA-256 hex of the file's current bytes. If it does not match, the tool returns error_kind stale and writes nothing.",
+  "type": "string"
+}
  2. First observedv0.32.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is known. The description adds genuine value by disclosing the line-ending insertion behavior, but says nothing about the stale-write protection (expected_sha256), error handling, or whether existing content is preserved — relevant for a destructive write tool.

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?

Two crisp sentences plus a concrete example. Purpose is front-loaded and the line-ending behavior follows immediately. The example earns its place by demonstrating the exact parameter shape, though it is slightly more verbose than strictly necessary.

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 destructive write tool with no output schema and a partly-documented schema, the description covers the core behavior and line-ending nuance but omits error/return semantics, the role of expected_sha256 staleness, and how it differs from create_file/prepend_file. Adequate but with clear gaps.

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?

Coverage is 50%: agent_preset and expected_sha256 are documented in the schema, while path and content carry no schema description. The description's example partially compensates by showing how path and content are used, but the ambiguity of agent_preset's interaction with append behavior is unaddressed. Baseline 3 is appropriate.

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+resource ('Append content to an existing file') that is clearly distinguishable from siblings like prepend_file, create_file, and replace_text. It doesn't explicitly name those siblings, so routing relies on the agent inferring the difference, keeping it just below a 5.

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 phrase 'to an existing file' implicitly signals this is not for creating files, but there is no explicit when-to-use guidance, no when-not-to-use, and no reference to alternatives such as prepend_file or create_file. The agent must infer the routing.

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

Deploy Server

Other Tools