markdown-vault-mcp

Note History

get_history

Read-onlyIdempotent

Retrieve the commit history for a note, attachment, folder, or whole vault, newest first, to inspect changes; returns no commits when Git history is unavailable.

Instructions

List the commits that touched a note, an attachment, a folder or the whole vault, newest first.

A vault without git history returns no commits.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_history"
  }
}

Input Schema

Name	Required	Description
`path`	No	A note or attachment path, such as `"notes/alpha.md"`, or a folder, such as `"guides"`; omit for the whole vault. Give a note's current name: history from before a rename is included.
`limit`	No	Maximum commits to return (default 20, at most 100).
`since`	No	Earliest commit date, inclusive: an ISO 8601 time such as `"2026-04-01T00:00:00"` or a relative date such as `"1 week ago"`; omit for all history.
`until`	No	Latest commit date, inclusive, in the same forms as since; omit for no upper bound.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv6.1.0Nov 2, 2026

changedInput schema / properties / limit / description

Previous value: -"Maximum number of commits to return. Default 20, max 100."New value: +"Maximum commits to return (default 20, at most 100)."

changedInput schema / properties / path / description

Previous value: -"Vault-relative path to filter on. A `.md` note or a\nconfigured attachment extension (png, pdf, svg, …) scopes to\nthat single file (e.g. \"notes/alpha.md\",\n\"assets/diagram.png\"); an existing folder scopes to its\nsubtree (e.g. \"guides\" returns commits touching guides/**).\nOmit (or pass null) for vault-wide commit history."New value: +"A note or attachment path, such as `\"notes/alpha.md\"`, or a folder, such as\n`\"guides\"`; omit for the whole vault. Give a note's current name:\nhistory from before a rename is included."

changedInput schema / properties / since / description

Previous value: -"ISO 8601 datetime string (\"2026-04-01T00:00:00\") or a git\ndate expression (\"1 week ago\"). Passed as --since to git log.\nOmit for full history."New value: +"Earliest commit date, inclusive: an ISO 8601 time such as\n`\"2026-04-01T00:00:00\"` or a relative date such as `\"1 week ago\"`; omit for\nall history."

changedInput schema / properties / until / description

Previous value: -"ISO 8601 datetime string or git date expression, passed as\n--until to git log. Both 'since' and 'until' boundaries are\ninclusive: a commit whose committer date equals either\nendpoint is included in the result. Omit to disable the upper\nbound."New value: +"Latest commit date, inclusive, in the same forms as since; omit for\nno upper bound."

Changed1 schema field changedv4.0.0Aug 26, 2026

changedInput schema / properties / path / description

Previous value: -"Vault-relative path of the note or attachment to filter on\n(e.g. \"notes/alpha.md\" or \"assets/diagram.png\"). May be a\n`.md` note or a configured attachment extension (png, pdf,\nsvg, …). Omit (or pass null) for vault-wide commit history."New value: +"Vault-relative path to filter on. A `.md` note or a\nconfigured attachment extension (png, pdf, svg, …) scopes to\nthat single file (e.g. \"notes/alpha.md\",\n\"assets/diagram.png\"); an existing folder scopes to its\nsubtree (e.g. \"guides\" returns commits touching guides/**).\nOmit (or pass null) for vault-wide commit history."

First observedv3.1.0Jul 8, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds two real behavioral facts: results are ordered newest first, and a vault without git history yields an empty list rather than an error. It says nothing about paging behavior or how commits are identified, but the output schema covers the return shape.

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?

Two sentences, front-loaded with the core action and scope, followed by the one precondition an agent must know. Nothing is wasted or redundant with the schema.

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?

For a read-only listing tool with a full parameter schema and an output schema, the description covers purpose, scope, ordering and the empty-result case, which is nearly everything needed. The remaining gap is routing guidance against the many sibling history/link tools.

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?

Schema description coverage is 100%, so path, limit, since and until are already fully documented with formats, defaults and bounds. The description adds only the ordering semantics implied by limit (newest commits first), which is marginal value over the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("List the commits that touched a note...") plus the scoping options and sort order (newest first), so an agent knows exactly what comes back. It does not name or contrast with the closest siblings such as get_diff or get_recent, so sibling differentiation is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the scope statement (history of a path or the whole vault) and the note that an empty result means no git history. There is no explicit guidance on when to choose this over get_diff (per-commit content) or get_recent (recently modified notes), which is the main gap given how many siblings overlap.

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