Skip to main content
Glama
Sign In
sessionwiki

sessionwiki

by necroz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Edit page fields

wiki_update_frontmatter
DestructiveIdempotent

Edit frontmatter fields like title, tags, lifecycle and confidence on an existing wiki page while keeping the body byte for byte. Preview changes without confirm=true to see old and new values first.

Instructions

Change frontmatter fields of one existing page under wiki/; the body is kept byte for byte. fields may set title, type, tags (a list that replaces the old one), lifecycle (draft, reviewed, verified, stale, archived) and confidence (0.0-1.0); other keys are refused. add_tags and remove_tags change the tag list without replacing it. last_updated is set to today. Refused for system pages and pages with origin: human. Without confirm=true it writes nothing and returns the old and new value of each field. Ask the user before confirm=true. Returns JSON {path, changes: {field: [old, new]}, written}. Use wiki_write_page to change the body and wiki_archive_page to retire a page.

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>"
    },
    "name": "wiki_update_frontmatter"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesExisting page path relative to the repo root, under wiki/.
fieldsNoFields to set: title, type, tags, lifecycle, confidence. Any other key is refused.
confirmNoRequired to actually write. Without confirm=true the call returns the old and new values and writes nothing.
add_tagsNoTags to add without replacing the current list.
remove_tagsNoTags to remove from the current list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag readOnlyHint=false, destructiveHint=true and idempotentHint=true, and the description adds substantive behavior beyond them: dry-run-by-default without confirm, the side effect that last_updated is set to today, tag replacement vs incremental tag edits, and refusal for system/human-origin pages. It even documents the refused-keys behavior and the exact return payload. No contradiction with annotations.

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 purpose and scope, and nearly every clause carries information (refusals, confirm protocol, return shape, alternatives). The single semicolon-chained block is dense, though; splitting the dry-run/confirm rule and the return shape into separate sentences would parse faster for an agent.

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?

No output schema exists, and the description compensates by describing the returned JSON ({path, changes: {field: [old, new]}, written}) and the dry-run behavior that produces it. With refusals, side effects, and sibling routing all covered, nothing material is missing for a nested-object mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the schema leaves 'fields' as an untyped object, so the description supplies the real contract: allowed keys (title, type, tags, lifecycle, confidence), the lifecycle value set (draft, reviewed, verified, stale, archived), the confidence range 0.0-1.0, replacement semantics for tags, and refusal of unknown keys. It also distinguishes add_tags/remove_tags as non-replacing, which is a meaningful semantic beyond the schema text.

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 and resource ('Change frontmatter fields of one existing page under wiki/') and immediately bounds the effect ('the body is kept byte for byte'), which separates it from body-writing tools. It names the sibling alternatives (wiki_write_page, wiki_archive_page) with their distinct purposes, so an agent can pick without opening schemas.

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?

Gives explicit routing rules to siblings for body edits and retiring pages, plus explicit exclusion conditions: refused for system pages and pages with origin: human. It also states the required interaction protocol ('Ask the user before confirm=true') and what happens without confirmation, which is exactly the when-to-use guidance an agent needs.

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