Alcoven

Add a document

add_document

Writes or saves a new document on the project (notes from a meeting, a plan, a report, a brief), or a new text file, under this person's name. A document is Markdown or plain text, at a name ending in .md, .markdown, .txt or .text; other text (data/prices.csv, config/site.yaml, src/app.ts) is kept as a file, up to 1 MB. A document takes a summary of one or two sentences for the project's overview and search: Alcoven keeps the summary given and writes none itself.

Input Schema

Name	Required	Description
`did`	No	What the person did themselves in this work, in a few words they agree with: what they chose or decided, what they corrected, rewrote or wrote, what they checked and against what. Start with the verb, in the past tense, in their language: "Chose the three-step plan; fixed the March totals; rewrote the opening". Say nothing of what you did, what they did not do, how long it took, or a share of the work. Pass no did when their part was the request and the yes. Everyone who sees the change reads it, people outside the team included. At most 300 characters.
`for`	No	Who this is for. "team" when any of it is for the team only: pay, rates or costs, a line the client should not read, personal data. Alcoven then keeps it from people who see only some folders until the person answers in Alcoven. "everyone" when all of it is fine for everyone who sees the folder.
`why`	No
`body`	Yes	The document in Markdown, or the file's text.
`path`	Yes	Where it goes, folders allowed: research/pricing-interviews.md for a document, data/prices.csv for a text file.
`read`	No	The § addresses you read for this work, kept with asked. Alcoven adds what it saw you read on this project since you last wrote on it, going back two hours at most.
`asked`	No	What the person asked for, in their own words, as they said it: their request only, never the rest of the conversation, and left out when they do not want it shared. It goes on the project with the change, so everyone who sees the change, and their AIs, see why it was made.
`title`	Yes	A document's title. A file is known by its name.
`for_why`	No	With "team": a few words saying what in it is for the team, like "our day rate for the bank". The person and the project's managers read them.
`project`	No	The project's slug, from open_project, like acme. Not needed when a § address names the project, or when the person is on one project.
`summary`	No	For a document: one or two sentences on what it holds, for the project's overview and search.
`asked_from`	No	Where the request came from, when the person says so, in a few words: "Tuesday's call with the bank", "Ines's email".

Output Schema

Name	Required	Description	Default
`draft`	No
`copied`	No
`address`	Yes
`checked`	No
`part_offer`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

addedInput schema / properties / did

Added value: +{
+  "description": "What the person did themselves in this work, in a few words they agree with: what they chose or decided, what they corrected, rewrote or wrote, what they checked and against what. Start with the verb, in the past tense, in their language: \"Chose the three-step plan; fixed the March totals; rewrote the opening\". Say nothing of what you did, what they did not do, how long it took, or a share of the work. Pass no did when their part was the request and the yes. Everyone who sees the change reads it, people outside the team included. At most 300 characters.",
+  "maxLength": 300,
+  "type": "string"
+}

First observedOct 22, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world. The description adds genuinely new behavioral facts: a 1 MB cap on non-document text files, the privacy consequence of for="team" (hidden from partial-folder viewers until the person answers), and that the summary is stored verbatim with none generated by Alcoven.

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?

Three sentences, front-loaded with the core action and the document-vs-file rule before the summary detail. The closing sentence mildly duplicates the schema's summary description, but the 'writes none itself' clause keeps it earning its place.

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 12-parameter creation tool with an output schema, the description covers classification, size limits, and privacy routing, which is solid. It leaves a notable gap: idempotentHint=false is never explained — an agent cannot tell whether writing to an existing path errors, overwrites, or versions — and the relationship to edit_document remains unstated.

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 92%, so the schema already documents nearly every parameter, including path examples, the for enum, and summary length. The description's mentions of path extensions and the summary sentence count largely restate the schema; it adds only the note that no summary is auto-written, which is slight added value over a high-coverage schema (baseline 3).

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: writes/saves a new document or text file on the project under this person's name. It also defines what counts as a document (.md/.markdown/.txt/.text) versus a kept file, which sharpens the concept. It stops short of naming the obvious siblings (edit_document, add_note), so an agent must still infer the create-vs-modify boundary.

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?

'Writes or saves a NEW document' implies creation and implicitly excludes editing, but there is no explicit instruction such as 'to change an existing document use edit_document' or 'for a short note use add_note'. Usage is inferable from the verb and the file-type paragraph, not stated.

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

All Alcoven tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?