tela

Overview Schema Source Related Servers Discussions Admin

Patch page section

patch_page

Edit a single section of a tela wiki page instead of rewriting the whole body. Use get_page format:"map" to find the target path, then apply append, prepend, replace, or delete.

Instructions

Surgically edit ONE section of a page instead of rewriting the whole body (editor+). First call get_page format:"map" to see the section paths, then patch the target. Cheaper and safer than update_page on a long page — it never touches the rest of the document. Snapshots a revision like any edit.

Input Schema

Name	Required	Description
`id`	Yes	page id to patch
`target`	Yes	the section to edit, by its heading path from get_page format:"map" (e.g. 'Setup' or 'Deploy > Production'); the bare heading text also resolves
`content`	No	markdown to insert; omit for delete
`operation`	Yes	append (add to the end of the section's body), prepend (add right under the heading), replace (swap the section's body, heading kept), or delete (remove the heading and its body). A section means the heading AND EVERYTHING NESTED UNDER IT until the next same-or-higher heading — so replace/delete on a '##' also removes its '###' sub-sections (they come back in the response as removed_subsections), and append lands after the last of them. To edit only the prose under a heading that has sub-sections, target the sub-section instead.
`base_version`	No	optional: the page version you last read. If the page has changed since, the patch is refused with version_conflict; re-read and reapply. Even without it, a patch never overwrites an edit made while it was being applied
`idempotency_key`	No	optional client-generated key; a retry with the same key returns the original result instead of re-applying the patch

Output Schema

Name	Required	Description	Default
`page`	Yes
`warning`	No
`removed_subsections`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.11.0Oct 15, 2026

addedInput schema / properties / base_version

Added value: +{
+  "description": "optional: the page version you last read. If the page has changed since, the patch is refused with version_conflict; re-read and reapply. Even without it, a patch never overwrites an edit made while it was being applied",
+  "type": [
+    "null",
+    "integer"
+  ]
+}

changedInput schema / properties / operation / description

Previous value: -"append (add to the end of the section's body), prepend (add right under the heading), replace (swap the section's body, heading kept), or delete (remove the heading and its body)"New value: +"append (add to the end of the section's body), prepend (add right under the heading), replace (swap the section's body, heading kept), or delete (remove the heading and its body). A section means the heading AND EVERYTHING NESTED UNDER IT until the next same-or-higher heading — so replace/delete on a '##' also removes its '###' sub-sections (they come back in the response as removed_subsections), and append lands after the last of them. To edit only the prose under a heading that has sub-sections, target the sub-section instead."

addedOutput schema / properties / page / properties / epistemic / properties / summary_stale
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / page / properties / sections / items / properties / in_quote
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / page / properties / status
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / page / properties / version
```
Added value: +{
+  "type": "integer"
+}
```

changedOutput schema / properties / page / required

Previous value: -[
-  "id",
-  "space_id",
-  "parent_id",
-  "title",
-  "body",
-  "position",
-  "created_at",
-  "updated_at",
-  "url"
-]New value: +[
+  "id",
+  "space_id",
+  "parent_id",
+  "title",
+  "body",
+  "position",
+  "created_at",
+  "updated_at",
+  "version",
+  "status",
+  "url"
+]

addedOutput schema / properties / removed_subsections

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}

addedOutput schema / properties / warning
```
Added value: +{
+  "type": "string"
+}
```

First observedv0.1.0Jul 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: the permission requirement ('editor+'), the isolation guarantee ('never touches the rest of the document'), and the side effect ('Snapshots a revision like any edit'), which also implies edits are recoverable. This is meaningful behavioral disclosure for a mutation tool whose annotations only give the readOnly/destructive flags.

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 tight sentences, front-loaded with the core scope claim, then the required workflow, then the comparative justification. The parenthetical '(editor+)' packs a permission requirement into two tokens; no sentence is wasted.

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?

An output schema exists, so return values need no explanation, and the full-coverage parameter schema handles the input details. The description covers the remaining gaps an agent needs: permission level, workflow ordering, side effects, and comparison to the sibling tool.

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 coverage is 100%, so the baseline is 3, but the description adds procedural meaning to the 'target' parameter by tying it to the get_page format:"map" workflow. It does not add syntax detail for content, operation, base_version, or idempotency_key beyond what the schema already documents.

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 ('surgically edit ONE section of a page') and immediately scopes it against the whole-body alternative ('instead of rewriting the whole body'), naming update_page and get_page so the agent can differentiate from siblings without opening schemas.

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 explicit when-to-use ('instead of rewriting the whole body'), names the alternative tool and the condition that favors it ('cheaper and safer than update_page on a long page'), and states a prerequisite workflow ('First call get_page format:"map" ... then patch the target'). Nothing is left to inference.

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