Skip to main content
Glama
Sign In
sessionwiki

sessionwiki

by necroz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Write a page

wiki_write_page
DestructiveIdempotent

Create or replace a Markdown wiki page under wiki/ with required frontmatter, returning a preview unless confirm=true to prevent accidental writes.

Instructions

Create or replace one Markdown page under wiki/. content is the whole page and must start with frontmatter that has title and type. The tool sets origin: agent and last_updated (today) in it. mode='create' (default) fails if the page exists; mode='replace' overwrites it. Refused for paths outside wiki/, non-.md files, wiki/archive/, system pages (index, log, overview, ...) and pages with origin: human. Without confirm=true it writes nothing and returns a preview. Ask the user before confirm=true. A real write is atomic and adds a line to wiki/log.md. Returns JSON {path, action, written, old_bytes, new_bytes}. Put new facts for review under wiki/candidates/. Use wiki_update_frontmatter to change only tags or fields, and wiki_archive_page instead of deleting.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>",
      "content": "<content>"
    },
    "name": "wiki_write_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNocreate (default) fails if the page exists; replace overwrites an existing page.create
pathYesPage path relative to the repo root, always under wiki/, for example wiki/concepts/Name.md.
confirmNoRequired to actually write. Without confirm=true the call returns a preview and writes nothing.
contentYesThe whole page: frontmatter with title and type, then the body. At most 1 MiB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), it discloses the tool-managed frontmatter fields (origin: agent, last_updated), the dry-run behavior without confirm=true, atomicity, and the wiki/log.md side effect. It also states the exact JSON return shape, which no output schema provides.

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?

Front-loaded with the core action, then constraints, then return value, then alternatives. Dense but every clause carries information; the only minor redundancy is repeating the mode and confirm semantics already present in the schema.

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 destructive write tool with four parameters and no output schema, everything an agent needs is present: preconditions, refusal rules, the preview/confirm protocol, side effects, and the response shape. Nothing material is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: content must be the whole page and must begin with frontmatter containing title and type, and the tool injects origin/last_updated into it. The confirm gate and mode semantics are largely restated from the schema, which keeps this from a 5.

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?

Opens with a specific verb pair and resource and scope: "Create or replace one Markdown page under wiki/". It immediately distinguishes itself from wiki_update_frontmatter and wiki_archive_page by naming them for their respective jobs.

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 the create-vs-replace condition, the refusal cases (non-.md, wiki/archive/, system pages, origin: human), the confirm gate, and the required user-approval step. It also routes to alternatives: wiki_update_frontmatter for tag/field-only edits, wiki_archive_page instead of deleting, and wiki/candidates/ for facts pending review.

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