Skip to main content
Glama

Cobrain

by space.cobrain
OverviewDiscussionsAdmin

write_file

Destructive

Create a note or REPLACE its whole content (a short text erases the rest; pass base). To add, use append_file; to change one part, patch_file.

Input Schema

NameRequiredDescriptionDefault
baseNoWhen replacing: the version read_file printed. If the note changed since, you are told to re-read and merge.
pathYes
contentYes
overwriteNo
workspaceNoUsually OMIT: the path finds its brain. Pass it only when a reply asks (new or ambiguous branch), with the brain the user named (if unclear ASK): id, 'mine', or owner name/email. A brain where the branch does not exist is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / base / description
      Previous value: -"The note's version as printed at the end of read_file (an ISO timestamp). Pass it when replacing an existing note."New value: +"When replacing: the version read_file printed. If the note changed since, you are told to re-read and merge."
    • changedInput schema / properties / workspace / description
      Previous value: -"Brain to act on: its id, «mio» (yours), or the owner's name/email as shown by search. Usually OMIT it: a path that already lives in one brain is found there, for reads and writes alike. Pass it only when the tool tells you to (a NEW branch, or one that exists in several brains) — with the brain the user named; when they were not explicit ASK THEM. A brain where the branch does not exist is refused even if you name it."New value: +"Usually OMIT: the path finds its brain. Pass it only when a reply asks (new or ambiguous branch), with the brain the user named (if unclear ASK): id, 'mine', or owner name/email. A brain where the branch does not exist is refused."
  2. First observed

TDQS

A4.4/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 safety profile is known. The description adds real value beyond that: it warns that a short content string 'erases the rest' and that passing `base` guards against clobbering concurrent edits (with a re-read/merge instruction). It does not cover permission/auth or the workspace refusal path, so not a 5.

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 tight sentences, zero filler, and the destructive scope is front-loaded before the alternatives. Every clause earns its place.

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 5-param mutation tool with no output schema and 40% schema coverage, the description covers the highest-risk semantics (full replacement, concurrency guard, sibling routing). The unmentioned `overwrite` flag and the workspace refusal path are minor residual 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?

Schema coverage is only 40%, and while the description usefully explains `base` and the destructive effect of `content`, it says nothing about `overwrite`, and only the schema covers `workspace`/`path`. It compensates partially but leaves gaps, so the baseline-for-low-coverage 3 is appropriate.

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?

States a specific verb+resource ('Create a note or REPLACE its whole content') and immediately names the two sibling tools it is not (append_file, patch_file). An agent can distinguish this from every other file tool without opening a schema.

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 routes: 'To add, use append_file; to change one part, patch_file', and flags the `base` parameter as required when replacing. This is exactly the when/when-not/alternatives guidance the dimension asks for.

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

All Cobrain toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources