leafwiki-mcp

Overview Schema Source Related Servers Discussions Admin

edit_page

Update a LeafWiki page by ID or path while preserving omitted fields; supply only the title, slug, content, tags, or properties you want to replace.

Instructions

Edit a page while preserving omitted fields.

Args: id: Page identifier, preferred when both selectors are supplied. path: Slash-separated page path. title: Optional replacement title; omitted values are preserved. slug: Optional replacement slug; omitted values are preserved. content: Optional replacement content; omitted values are preserved. tags: Optional replacement tags; omitted values are preserved. properties: Optional replacement properties; omitted values are preserved.

Returns: JSON-compatible updated page.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "edit_page"
  }
}

Input Schema

Name	Required	Description	Default
`id`	No
`path`	No
`slug`	No
`tags`	No
`title`	No
`content`	No
`properties`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 29, 2026

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose genuinely useful behavior: partial-update/merge semantics ('omitted values are preserved') and selector precedence (id preferred over path), and it states it returns the updated page. But it is silent on permissions, whether edits create revisions, concurrency/conflict behavior, and reversibility of a destructive-ish mutation.

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 core behavior is front-loaded in the first sentence, and the Args/Returns sections are tightly scoped. Given 0% schema coverage, each argument line earns its place rather than repeating schema data.

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?

Output schema exists, so the Returns line is mildly redundant, but the real gap is routing: with 30 siblings including several near-identical writers, the description never helps the agent choose this tool over them, nor does it cover mutation-specific concerns like revisions or permissions. Adequate but with clear gaps for a 7-param writer.

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 description coverage is 0%, so the description must compensate, and it does: all 7 params are explained, including selector precedence for id vs path, that path is slash-separated, and that each optional field is a replacement whose omission preserves the existing value. It stops short of detailing the properties key/value format beyond what the schema's type hints imply.

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+resource ('Edit a page') and adds the key semantic qualifier that omitted fields are preserved, which distinguishes it from a full-replace. However, it never names or contrasts with close siblings like append_to_page, update_page_tags, or update_page_properties, so an agent must infer scope from the schema alone.

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

Usage Guidelines2/5

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

No guidance on when to use this versus the many overlapping siblings (append_to_page for adding content, update_page_tags for tags only, update_page_properties for properties only). It also omits prerequisites such as needing an existing page or required permissions. The only usage hint is the selector precedence note.

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