Sumibako

Edit part of a page

edit_page

Change part of a page without sending the whole thing back. Append or prepend Markdown, or replace an exact piece of text with find and replace. Read the page first when using find: what you match against is the Markdown read_page returns. The text you match must appear exactly once, so include enough of the surrounding lines to make it unique. The previous version is kept for 14 days and the owner can restore it.

Input Schema

Name	Required	Description
`find`	No	Exact text to replace, as it appears in the page's Markdown. Must occur exactly once.
`icon`	No	Optional. Set the page's icon: one emoji.
`cover`	No	Optional. Set the page's cover, the banner across its top. One of: brush (one ink brush stroke on paper), blue-hour (blue mountains under a moon), contours (a contour map on paper), flow (dark flowing lines with amber threads), mist (grey ridges in mist), sundown (amber ridges at sunset), garden (a raked sand garden with stones), stars (constellations on a night sky), enso (an ink circle on paper), ridges (white ridgelines on black), doodles (small doodles on paper), doodles-night (the same doodles on black), boxes (white cubes, a few in black and amber), stitch (indigo cloth with white stitching), dawn (a soft gradient, sky blue to peach), dusk (a deep gradient, blue to violet and red). Or "none" for no cover. A picture the owner uploaded is never replaced.
`title`	No	Optional. Rename the page.
`append`	No	Markdown to add at the end of the page.
`prepend`	No	Markdown to add at the start of the page.
`project`	No	The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project.
`replace`	No	What to put in its place. An empty string deletes the matched text.
`documentId`	No	The page to change.
`externalId`	No	The key the page was filed under, instead of its id.

Output Schema

Name	Required	Description
`url`	Yes	Where the owner reads it, signed in.
`icon`	No	The emoji beside the title.
`cover`	No	The banner across the top of the page, by name. "uploaded" when it is a picture the owner put there.
`title`	Yes
`access`	No	Who can open the shareable link: anyone who has it, or only somebody who also has the passcode.
`created`	No
`passcode`	No	The passcode the link needs, when access is passcode. Give it to the user exactly as written, alongside the link.
`warnings`	No
`publicUrl`	No	The shareable link, when the page is published.
`documentId`	Yes
`isPublished`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / project

Added value: +{
+  "description": "The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project.",
+  "type": "string"
+}

First observedOct 14, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare this is a non-destructive mutation, and the description adds genuinely new context: a 14-day version history and owner-initiated restore. The exact-once matching constraint is also framed behaviorally. It does not state what happens on a failed or ambiguous match (atomicity, whether other fields are still applied), which matters for a mutation with ten optional parameters.

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?

Four tight sentences, front-loaded with the core capability and followed by the operational caveats in priority order. No filler, and the read_page dependency is stated before the uniqueness rule that depends on it.

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?

The content-editing path is well covered and an output schema handles return values, but the description never mentions the metadata operations (title, icon, cover) or project filing that account for five of the ten parameters. An agent relying on the prose alone would not know it can rename a page or set its icon here.

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 100%, so every parameter is already documented, making 3 the baseline. The description adds real value for find (uniqueness, Markdown source-of-truth) but says nothing about icon, cover, title, project, or externalId beyond what the schema provides.

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 (change part of a page) and enumerates the three content modes: append, prepend, and find/replace. The phrase 'without sending the whole thing back' implicitly contrasts it with write_page, but the sibling is never named. It also omits that this tool can set a page's title, icon, and cover, so the stated purpose is narrower than the actual tool.

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

Usage Guidelines4/5

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

Explicitly directs the agent to read_page first when using find and explains why: the match target is the Markdown read_page returns. It also gives a concrete usage rule for uniqueness ('include enough of the surrounding lines'), which is the main failure mode. It stops short of saying when to prefer this over write_page, or when to choose append/prepend instead of find/replace.

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

All Sumibako tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?