WebsitePublisher AI

Patch Page

patch_page

Destructive

Apply targeted changes to an existing page without sending the full content. base_version_hash is optional — if omitted, find/replace acts as the natural conflict guard. Operations: replace, delete, insert_before and insert_after, each anchored on a find string that must match exactly once. Prefer this over update_page for small edits; use update_page to replace the whole page.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "slug": "<slug>",
      "patches": "<patches>"
    },
    "name": "patch_page"
  }
}

Input Schema

Name	Required	Description
`slug`	Yes	The page slug to patch
`patches`	Yes	Array of patch operations. Each patch needs operation and find (exact string, must match exactly once in the page content). replace: also send replace (the new string). insert_before / insert_after: also send content (inserted directly before or after the find string). delete: removes the find string.
`project_id`	Yes	The project ID
`patch_summary`	No	Brief description of what was changed (optional, stored in version history)
`base_version_hash`	No	Optional. The current version_hash of the page. If provided and mismatched, returns 409 with details. If omitted, find/replace handles conflicts naturally.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 13, 2026

changedInput schema / properties / patches / description

Previous value: -"Array of patch operations. Each patch needs: operation (\"replace\" or \"delete\"), find (exact string to locate). For replace: also include replace (new string). The find string must match exactly once in the page content."New value: +"Array of patch operations. Each patch needs operation and find (exact string, must match exactly once in the page content). replace: also send replace (the new string). insert_before / insert_after: also send content (inserted directly before or after the find string). delete: removes the find string."

addedInput schema / properties / patches / items / properties / content

Added value: +{
+  "description": "Content to insert (required for insert_before and insert_after)",
+  "type": "string"
+}

changedInput schema / properties / patches / items / properties / operation / description

Previous value: -"Operation type: \"replace\" or \"delete\""New value: +"Operation type: \"replace\", \"delete\", \"insert_before\" or \"insert_after\""

addedInput schema / properties / patches / items / properties / operation / enum

Added value: +[
+  "replace",
+  "delete",
+  "insert_before",
+  "insert_after"
+]

Changed1 schema field changedJul 19, 2026

changedInput schema / properties / base_version_hash / description

Previous value: -"Optional. The version_hash from get_page response. If provided and mismatched, returns 409 with details. If omitted, find/replace handles conflicts naturally."New value: +"Optional. The current version_hash of the page. If provided and mismatched, returns 409 with details. If omitted, find/replace handles conflicts naturally."

Changed2 schema fields changedMay 5, 2026

changedInput schema / properties / base_version_hash / description

Previous value: -"The version_hash from get_page response. Ensures no conflicting changes."New value: +"Optional. The version_hash from get_page response. If provided and mismatched, returns 409 with details. If omitted, find/replace handles conflicts naturally."

changedInput schema / required

Previous value: -[
-  "project_id",
-  "slug",
-  "base_version_hash",
-  "patches"
-]New value: +[
+  "project_id",
+  "slug",
+  "patches"
+]

First observedMar 19, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the anchoring constraint (find "must match exactly once") and the conflict-guard semantics of omitting base_version_hash. It stops short of describing failure handling when find matches zero or multiple times, or any permission requirements.

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?

Three sentences, all load-bearing: capability, the optional-hash conflict behavior, and the sibling routing rule. The most decision-relevant content (operations and the update_page comparison) is front-loaded with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description covers operations, anchoring semantics, conflict handling, and sibling routing. It leaves out error behavior on non-matching or ambiguous find strings and any auth/permission prerequisites, which would matter for a destructive patch on shared content.

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 description coverage is 100% and the nested patches array documents each operation's required companion field (replace, content) in detail, so the schema carries the burden. The description largely restates that: listing the four operations and noting base_version_hash is optional. It adds little that the schema does not already say, so the baseline 3 applies.

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?

States a specific verb and resource ("Apply targeted changes to an existing page") plus the distinguishing mechanism: partial edits anchored on a find string rather than full-content replacement. It explicitly names the sibling it is not (update_page), so an agent can route correctly without opening either schema.

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?

Gives an explicit decision rule: "Prefer this over update_page for small edits; use update_page to replace the whole page." Both the when and the when-not are stated, along with the alternative tool by name.

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

All WebsitePublisher AI tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.