Skip to main content
Glama

append_wiki_page

Append markdown to the end of an existing wiki page to add your section safely. It never changes existing text, so concurrent appends don't conflict.

Instructions

Add markdown to the END of a page that already exists. This is the tool for writing what you learned into your own section of a shared page — the thing create_wiki_page cannot do without leaving you a second page of the same name. It ADDS ONLY: it cannot change or remove a word that is already on the page, which is exactly why it is safe to offer where a general edit is not. There is still no tool to edit or delete existing content; if you need to correct something you appended, append the correction. Takes NO version and never conflicts — two agents appending to the same page at the same moment both get their text, in whichever order the server serialises them, and neither is asked to retry. Markdown is converted server-side by the same parser create_wiki_page uses, so headings, lists, tables, code blocks and links all survive; lead with a heading if you want your section to be findable. The reply is the page's identity and its new version, deliberately NOT the page body — appending does not need you to have read the page, and getting the whole document back is the cost this tool exists to avoid. Markdown that is only whitespace is a 400 rather than a version bump for no change. Needs write access to the workspace: a read-only role or a guest key is a 403 and retrying cannot fix it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
page_uuidYesFrom get_wiki_tree or a search_wiki hit. A wiki uuid passed here is a 404, not a page
content_markdownYesAppended after everything already on the page. Longer than 100k characters is refused rather than truncated
Behavior5/5

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

With no annotations, the description carries full behavioral burden and does so comprehensively. It discloses the append-only safety model, concurrency behavior ('Takes NO version and never conflicts'), response shape ('deliberately NOT the page body'), whitespace-only edge case (400), and write-access requirements (403 for read-only/guest). No contradicting annotations exist.

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 is long but every sentence earns its place: purpose, safety, concurrency, formatting, response, error handling, and permissions. It is front-loaded with the core action and then layers necessary behavioral context. No redundant or filler sentences.

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?

With no annotations and no output schema, the description fully equips an agent to invoke the tool correctly and understand consequences. It covers when to use, key behaviors, return value, error conditions, and auth requirements, making it complete for a mutation tool of this complexity.

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?

Input schema covers both parameters at 100% with detailed descriptions, so baseline is 3. The description adds extra value for content_markdown by explaining server-side markdown rendering ('same parser create_wiki_page uses') and advising to 'lead with a heading' for findability. It doesn't add much for page_uuid, but the schema already handles that.

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 verb and scope: 'Add markdown to the END of a page that already exists.' It clearly distinguishes itself from the sibling tool create_wiki_page ('the thing create_wiki_page cannot do without leaving you a second page of the same name') and further clarifies its append-only nature ('cannot change or remove a word').

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 states when to use the tool ('This is the tool for writing what you learned into your own section of a shared page') and contrasts with create_wiki_page. It also provides guidance for corrections ('if you need to correct something you appended, append the correction') and notes that no edit/delete tool exists, which prevents misselection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Developyn/laver-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server