Skip to main content
Glama
metavert-io

LightCMS

by metavert-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

Merge Fork

merge_fork
Destructive

Merge all pages from a fork workspace into live content, updating matching URLs, creating missing pages, recording conflicts, and returning counts and IDs. Requires admin role.

Instructions

Merge all pages in a fork workspace into live content. Requires admin role.

For each page in the fork:

  • If a matching live page exists (same URL): updates it with the fork content (fork wins). If the live page was edited after the fork was created, records a conflict but still merges.

  • If no live page exists at that URL: creates a new live page. It keeps the publish state it had in the fork (normally draft) unless publish_new is true, which publishes it. Pages on hold always stay drafts.

After merging, the fork status changes to "merged", its page copies are deleted, and the created/updated counts are kept on the fork record. Published live pages are regenerated immediately.

Returns: updated and created counts, created_ids and updated_ids (live page IDs), not_published (new pages publish_new left as drafts, with the reason), and any conflicts detected.

ALWAYS confirm with the user before merging, as this pushes changes to the live site.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fork_idYesFork workspace ID to merge into live,required
publish_newNoAlso publish the pages this merge creates. Default false: new pages keep the publish state they had in the fork (normally draft). Pages on hold always stay drafts

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv7.3.4
    • addedInput schema / properties / publish_new
      Added value: +{
+  "description": "Also publish the pages this merge creates. Default false: new pages keep the publish state they had in the fork (normally draft). Pages on hold always stay drafts",
+  "type": "boolean"
+}
  2. First observedv4.2.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only flag destructiveHint=true and openWorldHint=false; the description goes well beyond that, spelling out per-page conflict handling, fork-wins precedence, publish-state preservation, the pages-on-hold exception, the post-merge state change (status becomes 'merged', copies deleted, counts retained), and immediate regeneration of published pages. That is exactly the additional context the annotations cannot carry.

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?

Purpose is front-loaded in one sentence, the per-page rules are laid out as a scannable list, and the return-value rundown and confirmation warning are cleanly separated. Despite its length, each block carries distinct operational information with no 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?

With no output schema, the description compensates by enumerating the returned fields (updated/created counts, created_ids, updated_ids, not_published, conflicts), and it covers the destructive/mutation implications, admin requirement, and side effects. Nothing an agent needs to call this correctly is missing.

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 both parameters are already documented, including publish_new's default and the hold exception. The description restates much of the same publish_new behavior rather than adding syntax or edge-case detail beyond it, so the baseline 3 is appropriate.

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 opening sentence states a specific verb (merge) and resource (fork workspace pages into live content), which cleanly distinguishes it from siblings like archive_fork, delete_fork, purge_fork_copies, and get_fork_diff. An agent can pick this tool without opening the schema.

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 states a concrete prerequisite (requires admin role) and an explicit operational rule (ALWAYS confirm with the user before merging, since it pushes changes to the live site). It does not, however, name alternatives or say when to prefer e.g. purge_fork_copies or archive_fork, so it stops short of full routing guidance.

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