markdown-vault-mcp

Overview Schema Source Related Servers Discussions Admin

get_metadata

Retrieve frontmatter metadata as JSON from a note. Provide the note's path relative to the vault root to access structured metadata.

Instructions

Get the frontmatter metadata from a note as JSON.

Args: note_path: Path to the note relative to vault root

Returns: JSON string with metadata or error description

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "note_path": "<note_path>"
    },
    "name": "get_metadata"
  }
}

Input Schema

Name	Required	Description	Default
`note_path`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Sep 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden. It states that the tool returns a JSON string with metadata or an error description, giving an agent a clear expectation. It does not explicitly confirm non-mutation, but the 'get' verb and metadata focus make the read-only behavior unambiguous enough for this simple tool.

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 compact and front-loaded: a one-sentence purpose, one required arg, and a return behavior. There is no extraneous text, and the Args/Returns structure makes the information scannable.

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 single-parameter getter with an output schema, this is nearly complete. It specifies the path semantics and the return/error behavior. A clearer statement about behavior when frontmatter is absent would make it fully airtight, but that is a minor gap.

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?

The input schema only defines note_path as a string, and schema description coverage is 0%. The description fills this gap completely by specifying 'Path to the note relative to vault root,' which is exactly what an agent needs to construct a valid call.

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: 'Get the frontmatter metadata from a note as JSON.' This clearly separates it from siblings like read_note (full note content) and update_metadata (mutation).

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?

The purpose implies when it is appropriate—when only frontmatter/metadata is needed—but there is no explicit 'use this instead of read_note' or any exclusions/alternatives. Usage context is inferred, not stated.

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