Skip to main content
Glama

write

Atomically replace whole text artifacts in a project branch, with null values deleting them; requires expected_head to guard against conflicting changes.

Instructions

Atomically replace whole text artifacts; null deletes. Requires the current expected_head.

Input Schema

NameRequiredDescriptionDefault
branchYes
changesYes
projectYes
expected_headYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does disclose real behavior beyond the schema: the write is atomic, it replaces whole artifacts (destructive to prior content), null performs a delete, and expected_head is a required optimistic-concurrency token. It omits what happens on a head mismatch (error vs. overwrite), whether missing artifacts are created, and any 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.

Conciseness4/5

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

Two short clauses, zero padding, and the core mutation behavior is front-loaded before the precondition. The terseness costs some clarity ('text artifacts' and the changes-map key semantics are never pinned down).

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, atomic, nested-object mutation tool with no annotations and no output schema, the essentials are present but incomplete: failure/conflict behavior on head mismatch, create-vs-replace semantics for new keys, and the return value are all unaddressed.

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 the description must compensate for four required parameters. It explains expected_head's role as the current head precondition and gives the semantics of the changes map values ('null deletes'), but leaves the keys of that nested map, plus project and branch, completely 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?

States a specific verb+resource: atomically replacing whole text artifacts, with null meaning deletion. It distinguishes itself implicitly from read/create/merge siblings by being a whole-artifact replace, though it never names an alternative and the term 'artifacts' is left undefined (files? documents? keys in the changes map?).

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 rather than stated: 'whole text artifacts' signals full-document replacement instead of incremental edits, and 'null deletes' signals a deletion path. There is no explicit when-to-use/when-not guidance versus create, merge, or branch, and no stated prerequisites such as the branch existing.

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