Skip to main content
Glama
Sign In
vault-engine

vault-engine

by Bagas10k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

vault_lint_note

Validate a single note against vault integrity rules—required frontmatter, kebab-case filenames, valid wikilinks, and doctrine closing lines—using a file path or raw content.

Instructions

[VAULT LINTER] Pindai satu catatan terhadap aturan integritas vault Otak-Koding:

  1. Kunci frontmatter wajib (judul, kategori, tag, tanggal_dibuat, terakhir_diperbarui, tautan_terkait).

  2. Penamaan berkas kebab-case (tanpa spasi/underscore).

  3. Tautan wikilink sah (tidak putus).

  4. Dua baris penutup doktrin (Skipped: dan Add when:). Bisa menerima path berkas absolut atau string isi teks catatan.

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": {
      "file_path_or_content": "<file_path_or_content>"
    },
    "name": "vault_lint_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
file_nameNo
vault_pathNo
file_path_or_contentYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full behavioral burden. It usefully discloses the concrete rule set being checked, but never states whether the tool is read-only or writes/modifies the note, nor whether it fails or reports on the first violation — meaningful gaps for a 'lint' operation. An output schema exists, so the absence of return-format detail is excusable.

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?

The bracketed tag plus a numbered rule list is front-loaded and scannable, with no filler sentences. The final line about accepted input forms is well placed at the end, though the numbered enumeration is somewhat longer than strictly necessary for four short checks.

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?

An output schema exists, so return values need not be described, and the rule list gives good coverage of what is validated. Still missing are the read-versus-write nature of the tool, the semantics of the two unexplained optional parameters, and any routing guidance versus the overlapping broken-link sibling — gaps that matter for a tool with three parameters and zero schema documentation.

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

Parameters2/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 compensate, and it only partially does: it clarifies that the required argument accepts either an absolute file path or raw note text, which genuinely resolves ambiguity. However, file_name and vault_path receive no explanation whatsoever, and their relationship to file_path_or_content (mutually exclusive? overrides?) is left entirely unclear.

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?

The description names a specific verb (lint/scan) and a specific resource (a single note), then enumerates the four integrity rules it enforces, so an agent knows exactly what class of check this performs. It stops short of distinguishing itself from vault_find_broken_links, which overlaps on rule 3 (broken wikilinks), leaving a small ambiguity among siblings.

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 only usage signal is the phrase 'Pindai satu catatan' (scan one note), which implies single-note scope but never states when to prefer this over vault_find_broken_links, vault_scaffold_note, or vault_inspect_graph. There are no when-not conditions, prerequisites, or named alternatives.

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

Deploy Server

Other Tools