Skip to main content
Glama

Replace the content of a page

replace-journal-page
DestructiveIdempotent

Replace a journal page's entire content in one write, optionally renaming it. Handles HTML or plain text, rejects empty content, and verifies the change.

Instructions

Replace the whole content of one text page, and optionally rename it, in one write. Content with HTML tags is stored exactly as sent. Plain text becomes paragraphs: a blank line starts a new paragraph, a single line break stays a break, and nothing is removed; Markdown is not converted, and the result says when the text looks like Markdown. Empty content is refused. The page is read back and compared; the result carries its length, not the content. To append instead, use journal-append-page. Needs the journal permission "create and change".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageIdYesId of the text page, from list-journals.
journalIdYesId of the journal, from list-journals.
newContentYesThe new content: HTML, or plain text that becomes paragraphs.
newPageNameNoNew name of the page. Leave out to keep the name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv14.2609.4

TDQS

A4.7/5.0
Behavior5/5

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

Despite annotations already covering readOnlyHint=false and destructiveHint=true, the description adds substantial behavioral context: HTML is stored exactly, plain text gets paragraph semantics, Markdown is not converted, empty content is refused, the page is read back and compared, and the result carries only length. It also discloses the required permission, which directly helps the agent assess feasibility.

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 dense but every clause earns its place: core operation, content transformation rules, refusal behavior, verification step, output shape, and a sibling pointer. The main action is front-loaded, and the prose stays tight without filler.

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 tool with four parameters and no output schema, the description provides a complete picture: what is replaced, how content formatting behaves, what happens on empty input, what the result contains, and what permission is required. Nothing essential for correct invocation 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 description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining how newContent is interpreted (HTML vs. plain text paragraph rules) and that empty content is rejected, which adds meaningful parameter semantics. It doesn't detail parameters in the same order, but the content transformation guidance is valuable.

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 resource: 'Replace the whole content of one text page, and optionally rename it.' It clearly distinguishes this from sibling tools like journal-append-page and journal-rename by naming an alternative. The subject and scope are unambiguous.

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?

It gives clear usage context by noting when to use this tool ('Replace the whole content') and explicitly points to journal-append-page as the alternative for appending. It does not enumerate all sibling alternatives such as journal-rename or journal-set-page, but the main when-to-use instructions are present and clear.

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