Datacron

Overview Schema Source Related Servers Discussions Admin

Rename note section

rename_note_section

Destructive

Rename an outdated H2-H6 Markdown section title without altering its level, content, or subordinate headings. Use content_hash CAS; rejects H1 and title collisions.

Instructions

Use this only to rename an outdated H2-H6 Markdown section title recognized by the current write selector, without changing its level, content, or subordinate headings. Pass the note's current content_hash as expected_hash for CAS. It refuses H1 because frontmatter title synchronization is outside this tool and refuses collisions recognized by the same AST selector. ATX and Setext headings are supported; fenced-code headings are ignored. For duplicate titles, pass 1-based heading_occurrence with heading_level and the exact expected_hash; the ordinal follows document order for those hashed bytes. Do not use chunk_id.

Input Schema

Name	Required	Description	Default
`heading`	Yes
`rel_path`	Yes
`request_id`	No
`new_heading`	Yes
`expected_hash`	No
`heading_level`	No
`heading_occurrence`	No

Output Schema

Name	Required	Description	Default
`indexed`	Yes
`renamed`	No
`rel_path`	No
`replayed`	No
`committed`	No
`content_hash`	Yes
`operation_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.1.17Oct 17, 2026
- addedOutput schema / description
```
Added value: +"Successful ``rename_note_section`` payload."
```
- removedOutput schema / properties / committed / default
```
Removed value: -null
```
- removedOutput schema / properties / operation_id / default
```
Removed value: -null
```
- removedOutput schema / properties / rel_path / default
```
Removed value: -null
```
- removedOutput schema / properties / renamed / default
```
Removed value: -null
```
- removedOutput schema / properties / replayed / default
```
Removed value: -null
```

Changed9 schema fields changedv0.1.5Sep 5, 2026

addedInput schema / properties / request_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Request Id"
+}

addedOutput schema / properties / committed

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Committed"
+}

addedOutput schema / properties / operation_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Operation Id"
+}

addedOutput schema / properties / rel_path

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Rel Path"
+}

removedOutput schema / properties / renamed / $ref
```
Removed value: -"#/$defs/RenamedSectionOutput"
```

addedOutput schema / properties / renamed / anyOf

Added value: +[
+  {
+    "$ref": "#/$defs/RenamedSectionOutput"
+  },
+  {
+    "type": "null"
+  }
+]

addedOutput schema / properties / renamed / default
```
Added value: +null
```

addedOutput schema / properties / replayed

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Replayed"
+}

changedOutput schema / required

Previous value: -[
-  "renamed",
-  "content_hash",
-  "indexed"
-]New value: +[
+  "content_hash",
+  "indexed"
+]

Addedv0.1.3Aug 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare destructive=true and idempotent=false, but the description adds substantial context beyond them: CAS via expected_hash, H1 refusal, collision refusal through the same AST selector, ATX/Setext support with fenced-code exclusion, and duplicate-title ordinal resolution. This is unusually rich behavioral disclosure for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core scope sentence and dense but largely non-redundant detail after it. Sentences are long and pack several constraints each, but for a 7-parameter CAS-guarded mutation tool the length is justified.

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?

With an output schema present, return values need no explanation, and the description covers refusals, CAS, markdown dialect handling, and duplicate resolution. Missing coverage of rel_path and request_id slightly weakens completeness for a 7-parameter 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 0%, so the description must carry parameter meaning, and it does for expected_hash (CAS semantics), heading_level, and heading_occurrence (1-based, document order over hashed bytes). It leaves rel_path, request_id, and heading itself unexplained, so it does not fully close the coverage gap.

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 (rename), resource (H2-H6 Markdown section title), and scope limits, which cleanly separates it from siblings like move_note_section, delete_note_section, and patch_note_section. An agent can identify the operation 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?

"Use this only to rename..." plus explicit refusals (H1, collisions, chunk_id) give clear when-to-use and when-not boundaries. It stops short of naming a sibling alternative for the H1/frontmatter-title case, so it is strong but not fully routing.

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