markdown-vault-mcp

Overview Schema Source Related Servers Discussions Admin

capture_content

Store notes, tasks, or logs directly into your markdown vault's configured capture location by providing a name and content, with optional extra variables.

Instructions

Capture content into a configured capture location.

Args: name: Name of the capture (e.g., 'inbox', 'log'). text: Main content to capture (passed as 'text' variable). extra_vars: Optional dictionary of additional variables.

Returns: Result of the capture command.

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": {
      "name": "<name>",
      "text": "<text>"
    },
    "name": "capture_content"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`text`	Yes
`extra_vars`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Sep 6, 2026

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description must bear the full burden of behavioral disclosure. It reveals only that content is captured and a result is returned, leaving unclear whether the operation appends, overwrites, creates files, requires prior configuration, or produces side effects.

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 summary sentence is front-loaded and the Args/Returns structure is clean, with no redundant filler. Every line conveys either parameter meaning or return behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the basic call contract – what it does, its parameters, and that it returns a result – and an output schema exists to describe return values. It lacks context about the configured capture location, configuration requirements, and when this generic capture tool should be preferred over more specific siblings.

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

Parameters4/5

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

Although schema description coverage is 0%, the description defines all three parameters: name with concrete examples, text as the main content bound to a 'text' variable, and extra_vars as optional additional variables. This adds real meaning beyond raw types, though extra_vars usage remains somewhat underspecified.

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 clear action – capture content – and identifies the destination as a configured capture location, with concrete name examples (inbox, log) in the args. However, it does not distinguish capture_content from closely related siblings such as add_to_inbox or log_to_daily_note, so it is clear but not differentiated.

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

Usage Guidelines2/5

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

The description offers no guidance on when to use this tool instead of sibling capture/write tools such as add_to_inbox, log_to_daily_note, or create_note. There is no mention of prerequisites, exclusions, or context that would help an agent pick this over alternatives.

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