Skip to main content
Glama

edit_side_page

Update side page metadata (name, slug, instructions) and text-page content. Renames rewrite internal references; every write creates a draft version for undo.

Instructions

Update a side page's page-level metadata and, for type:"text" pages only, its content. Metadata (any side-page type): name (display title, shown in auto-generated footer/nav 'Solutions' links and breadcrumbs), newKey (rename the URL-slug fragment; old URL 404s, no redirect; internal references are rewritten in the background), and instructions (stored as an annotation for future context — does NOT trigger an AI edit). Content — type:"text" pages ONLY: title and/or htmlContent. Text side pages store a flat {title, htmlContent} document, not per-section overrides, so this is the direct way to write their content — landing/comparison pages have no title/htmlContent fields and must use set_side_page_section (or set_side_page_section with instructions-only for an AI rewrite of a text page's whole document) instead. Passing only one of title/htmlContent fetches and preserves the other automatically, so a partial write never clobbers the unset field. Every edit creates a new draft version (see list_side_page_versions / restore_side_page_version) — nothing here is destructive, any write (including a bad title/htmlContent edit) can be undone by restoring a prior version. On a published page, edits stay draft-only until set_side_page_state({published:true}) publishes them. When newKey triggers a reference rewrite, the response includes slugRewriteOperationId — poll it to confirm the cascade finished.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew display title for the side page. This is the title shown in auto-generated footer/nav 'Solutions' links and breadcrumbs. Changing it updates those links automatically.
slugYesParent landing page slug
titleNotype:"text" pages only: new page title (part of the flat {title, htmlContent} content document — different from `name`, which is the nav/footer display label). If `htmlContent` isn't also passed, the current htmlContent is fetched and preserved. Ignored for landing/comparison pages — use set_side_page_section there.
newKeyNoNew URL-slug fragment to RENAME the side page's key. The old URL will stop working (404) after rename — there is no redirect. Existing internal links from blogs/other pages to this page are rewritten automatically in the background (poll the returned slugRewriteOperationId).
sideKeyYesSide page key
htmlContentNotype:"text" pages only: new HTML body (part of the flat {title, htmlContent} content document). If `title` isn't also passed, the current title is fetched and preserved. Ignored for landing/comparison pages — use set_side_page_section there.
instructionsNoUpdated instructions for the AI
updateReferencesNoWhen renaming via newKey, rewrite existing internal references (blog backlinks, internalLinks) to point at the new slug. Defaults to true; set false to skip the cascade.
Behavior5/5

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

No annotations, so description must disclose side effects. It thoroughly covers draft-version creation, non-destructive writes, draft-only publishing, 404 on rename, background reference rewrites, and the slugRewriteOperationId polling requirement.

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?

Long but information-dense; each sentence adds new behavioral or contextual detail, organized into clear segments.

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 an 8-param tool with no output schema, the description covers parameter applicability, side effects, versioning, publishing, and the async operation response field, leaving no major gaps.

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?

Schema coverage is 100%, but the description adds critical semantics: title vs name distinction, flat document vs section overrides, partial-write preservation, and instructions not triggering AI edits.

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 ('Update') and resource ('side page'), scopes to metadata and content (type:text only), and distinguishes from siblings by explicitly naming set_side_page_section for non-text pages.

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 when NOT to use this tool (landing/comparison pages) and directs to set_side_page_section; also explains versioning and publishing alternatives (list_side_page_versions, set_side_page_state).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitsandtea/postking-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server