Skip to main content
Glama
VBlackJack

Datacron

by VBlackJack
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Patch note preamble

patch_note_preamble
Destructive

Replace or remove the preamble before the first Markdown heading in a note. Use an exact hash to safely update or delete introductory content while preserving the heading and body.

Instructions

Use this to replace or remove content strictly before the first Markdown heading recognized by the current write selector. Pass the note's exact expected_hash for CAS. Empty or whitespace-only new_content removes the preamble. The first heading and all following content preserve exact bytes when the file uses uniform line endings; mixed-EOL files follow the existing global dominant-EOL normalization. Notes without a recognized Markdown heading are refused fail-closed. The shared AST selector supports ATX and Setext headings, normalizes closing hashes, and ignores headings inside fenced code.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rel_pathYes
request_idNo
new_contentYes
expected_hashYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexedYes
patchedNo
rel_pathNo
replayedNo
committedNo
content_hashYes
operation_idNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed9 schema fields changedv0.1.5
    • 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"
+}
    • removedOutput schema / properties / patched / $ref
      Removed value: -"#/$defs/PatchedPreambleOutput"
    • addedOutput schema / properties / patched / anyOf
      Added value: +[
+  {
+    "$ref": "#/$defs/PatchedPreambleOutput"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedOutput schema / properties / patched / default
      Added value: +null
    • addedOutput schema / properties / rel_path
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Rel Path"
+}
    • addedOutput schema / properties / replayed
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Replayed"
+}
    • changedOutput schema / required
      Previous value: -[
-  "patched",
-  "content_hash",
-  "indexed"
-]New value: +[
+  "content_hash",
+  "indexed"
+]
  2. Addedv0.1.3

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses exact mutation scope, CAS requirements, empty-content removal semantics, byte-preservation behavior under uniform vs mixed line endings, and fail-closed refusal for unheaded notes. It also explains the shared AST selector's edge-case behavior with ATX/Setext headings and fenced code. This is rich behavioral context that annotations alone cannot provide.

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?

The description is dense but every sentence earns its place: operation, CAS, removal semantics, EOL behavior, fail-closed behavior, and selector details. The main usage guidance is front-loaded, with edge cases following logically. There is no filler or repetition of schema information.

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?

Given the tool's complexity and the presence of an output schema, the description is complete. It covers what the tool does, how the heading selector behaves, when it refuses, how content removal works, and how byte preservation behaves across EOL styles. Nothing an agent needs to call this tool correctly is materially missing.

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?

With 0% schema description coverage, the description compensates by explaining the key parameters: expected_hash must be the note's exact CAS value, and new_content can be empty or whitespace-only to remove the preamble. rel_path is not explicitly described, but its title 'Rel Path' makes its role clear. request_id is not explained, but it is optional and likely a standard correlation identifier, so this is a minor 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?

The description opens with a specific verb and resource: 'replace or remove content strictly before the first Markdown heading.' This precisely defines the tool's scope and distinguishes it from siblings like patch_note_section, which target different structural regions. The operation is immediately understandable from the first sentence.

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?

The description explicitly says 'Use this to...' and clearly defines when the tool applies: only to content before the first recognized Markdown heading. It also states that notes without such a heading are refused fail-closed, giving a hard boundary. It does not explicitly name alternatives or say when to prefer a sibling tool, which keeps it just short of a 5.

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/VBlackJack/Datacron'

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