Skip to main content
Glama

write_org_doc

Persist something durable — a resolved answer, a runbook, a decision — so the next agent inherits it. Ephemeral chat output is lost. Commits immediately if your grant allows it, and is refused if it does not. The confirmation says whether it CREATED the document or OVERWROTE one, names any directory that did not exist before (check it against what you meant — a typo in folder_path silently mints a new one), and carries a console link you can hand to a person. Set metadata with YAML frontmatter at the top of content: type (one of: meeting-notes, playbook, spec, brand-asset, web-clip, contract, misc — anything else becomes misc), title, summary, and tags as a list. tags is the write-side spelling of what the listing tools call label. status takes active or inactive and is not a label: inactive retires a document — it stays in the folder and stays openable in the console, but agents stop retrieving it. Omit it unless you mean to retire something.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesthe document name, e.g. "Q3 summary.md". Cannot contain "/" — put folders in folder_path instead. END IT IN .md unless you mean otherwise: only .md and .mdx render in the console, and anything else opens as plain text with no way to switch. Nothing is appended for you.
shareNothe share id, when this location was shared with you from another workspace — list_org_folders prints it. Omit for your own folders.
tokenNoBearer token identifying the principal. Usually omitted — supplied by the transport (HTTP Authorization header or the server's AGENTLEFS_TOKEN env). Only pass this to override.
contentYes
folder_pathYesfolder names, outermost first, e.g. ["handbook","policies"]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden. It discloses immediate commitment or refusal based on the grant, the created-vs-overwritten confirmation detail, the silent creation of new directories from folder_path typos, and the exact retirement semantics of inactive status. This is exceptionally transparent about side effects.

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?

The description front-loads the core purpose in the first sentence and then packs commit behavior, confirmation semantics, metadata rules, and status meaning into dense, operationally relevant sentences. There is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with no output schema and no annotations, the description covers purpose, permission refusal, side effects, confirmation response contents, and metadata options. An agent has enough information to invoke it safely and correctly.

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?

The schema already documents name, share, token, and folder_path, and the description adds the otherwise-missing meaning of content via YAML frontmatter, type mapping, tags/label relationship, and status behavior. It also adds a valuable warning about folder_path typos. It does not revisit every parameter, but it goes beyond the baseline.

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?

The description opens with a specific action, 'Persist something durable,' and identifies the resource as an organization document that later agents inherit. It also clarifies that the operation either CREATES or OVERWRITES a document, which positions it clearly against siblings like edit_org_doc, delete_org_doc, and read_org_doc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear context for use: persist answers, runbooks, or decisions so they outlive ephemeral chat output, and it explains when to omit or include status. It does not explicitly name sibling alternatives or state when not to use the tool, so it stops short of full 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources