Skip to main content
Glama
pvliesdonk

markdown-vault-mcp

by pvliesdonk
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Hybrid

Note History

get_history
Read-onlyIdempotent

List git commits that changed a note, folder, or entire vault. Filter by path and date range to trace when Markdown files were modified.

Instructions

List commits that touched a note, folder, or the whole vault.

Only available for git-backed vaults. Use 'stats' to check whether git is configured, or call this and handle the error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoVault-relative path to filter on. A `.md` note or a configured attachment extension (png, pdf, svg, …) scopes to that single file (e.g. "notes/alpha.md", "assets/diagram.png"); an existing folder scopes to its subtree (e.g. "guides" returns commits touching guides/**). Omit (or pass null) for vault-wide commit history.
limitNoMaximum number of commits to return. Default 20, max 100.
sinceNoISO 8601 datetime string ("2026-04-01T00:00:00") or a git date expression ("1 week ago"). Passed as --since to git log. Omit for full history.
untilNoISO 8601 datetime string or git date expression, passed as --until to git log. Both 'since' and 'until' boundaries are inclusive: a commit whose committer date equals either endpoint is included in the result. Omit to disable the upper bound.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. Changed1 schema field changedv4.0.0
    • 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."
  2. First observedv3.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already classify this as readOnly, idempotent, and non-destructive. The description adds a meaningful behavioral constraint: the tool only works on git-backed vaults and can raise an error otherwise, which is not inferable from the schema or annotations.

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 deliver the purpose and the key precondition without redundancy. The core action is front-loaded, and the git prerequisite and stats fallback are presented immediately after.

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 output schema, detailed parameter docs, and annotations, the description covers the essential contextual gap—git dependency and error handling. An agent can decide whether to call it and what to do if the vault isn't git-backed.

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 coverage is 100% with detailed descriptions for path (vault-relative, file/folder subtree semantics), limit (default/max), and since/until (ISO 8601 or git expressions, inclusive boundaries). The description contributes no additional parameter meaning, so the baseline of 3 applies.

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 'List commits that touched a note, folder, or the whole vault,' giving a specific verb and resource while scoping the operation to git-backed vaults. This clearly distinguishes it from content-reading siblings like read and search, and from diff/recent variants like get_diff and get_recent.

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 states the precondition (git-backed vault) and gives an actionable fallback: use 'stats' to check whether git is configured, or call this and handle the error. It does not enumerate alternatives, but the precondition provides a clear selection rule versus non-git history tools.

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/pvliesdonk/markdown-vault-mcp'

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