Datacron

Overview Schema Source Related Servers Discussions Admin

Get a note

get_note

Read-only

Fetch full note context by ULID, chunk ID, or vault path before answering from a search snippet. Retrieve full text, heading maps, chunks, or metadata with paging.

Instructions

Fetch the full context behind a search hit before answering from a snippet alone. Fetch a single note by its ULID, indexed chunk_id, or vault-relative path. chunk_id inputs return format='chunk' with the sandbox-wrapped chunk body; a parent-hash mismatch returns an explicit stale-chunk error. Chunk reads ignore offset/limit. For note inputs, format='full' returns the sandbox-wrapped body and offset/limit page large notes by character range; format='map' pages the heading outline (offset/limit count headings); format='metadata' pages a sanitized JSON string in metadata_json (offset/limit count characters; concatenate pages then parse JSON). Read next_offset until null with an unchanged content_hash. Large inline metadata is omitted with metadata_truncated=true. All successful read envelopes obey DATACRON_MAX_READ_RESPONSE_CHARS. heading_path selects exact rendered heading ancestry including its subtree; repeated paths require a 1-based heading_occurrence. Section reads require full format and a note input, include source line spans and the original note hash, and paginate relative to the redacted section.

Input Schema

Name	Required	Default
`limit`	No
`format`	No	full
`offset`	No
`id_or_path`	Yes
`heading_path`	No
`heading_occurrence`	No

Output Schema

Name	Required	Description	Default
`id`	No
`tags`	No
`title`	No
`total`	No
`format`	Yes
`offset`	No
`aliases`	No
`content`	No
`created`	No
`note_id`	No
`section`	No
`updated`	No
`chunk_id`	No
`headings`	No
`line_end`	No
`rel_path`	Yes
`returned`	No
`writable`	No
`truncated`	No
`line_start`	No
`chunk_count`	No
`frontmatter`	No
`header_path`	No
`next_offset`	No
`total_chars`	No
`content_hash`	No
`source_mount`	No
`source_vault`	No
`limit_applied`	No
`metadata_json`	No
`next_chunk_id`	No
`prev_chunk_id`	No
`returned_chars`	No
`estimated_tokens`	No
`note_content_hash`	No
`chunk_content_hash`	No
`metadata_truncated`	No
`content_hash_contract`	No
`returned_estimated_tokens`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.1.18Oct 18, 2026

changedInput schema / properties / format / enum

Previous value: -[
-  "full",
-  "map",
-  "chunk"
-]New value: +[
+  "full",
+  "map",
+  "chunk",
+  "metadata"
+]

changedOutput schema / description

Previous value: -"Successful ``get_note`` payload across full, map, and chunk formats."New value: +"Successful ``get_note`` payload across body, map, chunk, and metadata formats."

changedOutput schema / properties / format / enum

Previous value: -[
-  "full",
-  "map",
-  "chunk"
-]New value: +[
+  "full",
+  "map",
+  "chunk",
+  "metadata"
+]

addedOutput schema / properties / metadata_json

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Metadata Json"
+}

addedOutput schema / properties / metadata_truncated

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Metadata Truncated"
+}

addedOutput schema / properties / returned

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Returned"
+}

addedOutput schema / properties / source_mount

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Source Mount"
+}

changedOutput schema / properties / source_vault / anyOf

Previous value: -[
-  {
-    "enum": [
-      "docs",
-      "memory"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "docs",
+      "memory",
+      "extra"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedOutput schema / properties / total

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Total"
+}

Changed36 schema fields changedv0.1.17Oct 17, 2026
- addedOutput schema / description
```
Added value: +"Successful ``get_note`` payload across full, map, and chunk formats."
```
- removedOutput schema / properties / aliases / default
```
Removed value: -null
```
- removedOutput schema / properties / chunk_content_hash / default
```
Removed value: -null
```
- removedOutput schema / properties / chunk_count / default
```
Removed value: -null
```
- removedOutput schema / properties / chunk_id / default
```
Removed value: -null
```
- removedOutput schema / properties / content / default
```
Removed value: -null
```
- removedOutput schema / properties / content_hash / default
```
Removed value: -null
```
- removedOutput schema / properties / content_hash_contract / default
```
Removed value: -null
```
- removedOutput schema / properties / created / default
```
Removed value: -null
```
- removedOutput schema / properties / estimated_tokens / default
```
Removed value: -null
```
- removedOutput schema / properties / format / default
```
Removed value: -null
```
- removedOutput schema / properties / frontmatter / default
```
Removed value: -null
```
- removedOutput schema / properties / header_path / default
```
Removed value: -null
```
- removedOutput schema / properties / headings / default
```
Removed value: -null
```
- removedOutput schema / properties / id / default
```
Removed value: -null
```
- removedOutput schema / properties / limit_applied / default
```
Removed value: -null
```
- removedOutput schema / properties / line_end / default
```
Removed value: -null
```
- removedOutput schema / properties / line_start / default
```
Removed value: -null
```
- removedOutput schema / properties / next_chunk_id / default
```
Removed value: -null
```
- removedOutput schema / properties / next_offset / default
```
Removed value: -null
```
- removedOutput schema / properties / note_content_hash / default
```
Removed value: -null
```
- removedOutput schema / properties / note_id / default
```
Removed value: -null
```
- removedOutput schema / properties / offset / default
```
Removed value: -null
```
- removedOutput schema / properties / prev_chunk_id / default
```
Removed value: -null
```
- removedOutput schema / properties / rel_path / default
```
Removed value: -null
```
- removedOutput schema / properties / returned_chars / default
```
Removed value: -null
```
- removedOutput schema / properties / returned_estimated_tokens / default
```
Removed value: -null
```
- removedOutput schema / properties / section / default
```
Removed value: -null
```
- addedOutput schema / properties / source_vault
```
Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "docs",
+        "memory"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Source Vault"
+}
```
- removedOutput schema / properties / tags / default
```
Removed value: -null
```
- removedOutput schema / properties / title / default
```
Removed value: -null
```
- removedOutput schema / properties / total_chars / default
```
Removed value: -null
```
- removedOutput schema / properties / truncated / default
```
Removed value: -null
```
- removedOutput schema / properties / updated / default
```
Removed value: -null
```
- addedOutput schema / properties / writable
```
Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Writable"
+}
```
- addedOutput schema / required
```
Added value: +[
+  "format",
+  "rel_path"
+]
```

Changed4 schema fields changedv0.1.10Sep 13, 2026

addedInput schema / properties / heading_occurrence

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Heading Occurrence"
+}

addedInput schema / properties / heading_path

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

addedOutput schema / $defs / NoteSectionOutput

Added value: +{
+  "description": "Selected heading subtree; physical line bounds are inclusive and 1-based.",
+  "properties": {
+    "heading_occurrence": {
+      "title": "Heading Occurrence",
+      "type": "integer"
+    },
+    "heading_path": {
+      "items": {
+        "type": "string"
+      },
+      "title": "Heading Path",
+      "type": "array"
+    },
+    "line_end": {
+      "title": "Line End",
+      "type": "integer"
+    },
+    "line_start": {
+      "title": "Line Start",
+      "type": "integer"
+    },
+    "matching_headings": {
+      "title": "Matching Headings",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "heading_path",
+    "heading_occurrence",
+    "matching_headings",
+    "line_start",
+    "line_end"
+  ],
+  "title": "NoteSectionOutput",
+  "type": "object"
+}

addedOutput schema / properties / section

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

First observedv0.1.0Jul 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare the safety profile (readOnly, non-destructive), while the description adds substantial behavioral detail the schema cannot convey: stale-chunk errors on parent-hash mismatch, chunk reads ignoring offset/limit, per-format pagination semantics, reading next_offset until null with an unchanged content_hash, metadata_truncated flagging, and the DATACRON_MAX_READ_RESPONSE_CHARS cap. This is exactly the kind of context that goes beyond structured fields.

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 motivation and identity of the tool, then progresses through format-specific behavior. Every sentence carries real information, though the dense single-block prose around format/offset semantics could be easier to scan if slightly more segmented.

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?

For a 6-parameter read tool with an output schema, the description covers identifier kinds, all format modes, pagination, error conditions, and section-read requirements, so nothing an agent needs to invoke it correctly is missing. Return-shape details are partly covered by the output schema, so the extra envelope notes are additive rather than redundant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry all parameter meaning, and it does: it defines all four format enum values with their distinct return and pagination behavior, explains id_or_path's three accepted identifier kinds, and clarifies offset/limit semantics per format (character range, heading count, character count) plus 1-based heading_occurrence for repeated paths.

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+resource ('Fetch a single note by its ULID, indexed chunk_id, or vault-relative path') and immediately distinguishes itself from the search siblings by framing itself as the follow-up to a search hit. An agent can tell this apart from search_text, list_notes, and get_note_history without opening any 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?

The opening sentence gives clear context ('before answering from a snippet alone'), effectively telling the agent to use this after a search. However, no explicit alternatives or 'when not to use' conditions are named (e.g., vs get_backlinks or get_note_history), so it stops short of full routing guidance.

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