Datacron

Overview Schema Source Related Servers Discussions Admin

Get note operation history

get_note_history

Read-only

Retrieve committed operation metadata for a note and check which versions can be restored, without reading content or modifying the journal. Filter by request_id to obtain a write receipt.

Instructions

Filter by request_id to retrieve an ordinary-write receipt. List committed operation metadata for one note without reading history content or modifying the journal. Each operation carries restore_available, saying whether its before_hash is still on disk and can therefore be passed to revert_note; history_stored alone only says the bytes were stored when the write committed, not that retention has kept them.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`note`	Yes
`limit`	No
`request_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.5Sep 5, 2026

addedInput schema / properties / request_id

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

First observedv0.1.0Jul 31, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already assert read-only and non-destructive, and the description reinforces this while adding the retention distinction between restore_available and history_stored, which is not visible in the schema. This helps agents avoid wrongly assuming a restore is always possible.

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?

Three dense sentences carry the core action, scope, and a nuanced caveat without padding. The first sentence leads with a secondary use case rather than the main listing behavior, but it is still economical.

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?

Combined with the output schema and read-only annotations, the description covers the essential decision logic, including when a restore is possible, and routes to revert_note. Minor undefined terminology ('ordinary-write receipt') and lack of limit semantics keep it from being fully complete.

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?

The request_id parameter gets real semantics (filter to a single write receipt) and the response field restore_available is explained. However, note and limit are left to their bare schema names, which is a gap given 0% schema description coverage.

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 states a specific action ('List committed operation metadata for one note') and explicitly scopes what it does not do ('without reading history content or modifying the journal'), separating it from get_note and write/restore tools. The phrase 'ordinary-write receipt' is domain-specific, but the main purpose remains unambiguous.

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 specifies the request_id path for retrieving a write receipt and tells the agent that restore_available determines whether before_hash can be passed to revert_note. It does not explicitly enumerate sibling alternatives, but the conditional guidance is concrete and actionable.

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