Skip to main content
Glama
Sign In
vault-engine

vault-engine

by Bagas10k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

vault_search

Search Obsidian vault notes by title or content keywords and filter results by tag or directory category to locate relevant records.

Instructions

[FAST VAULT SEARCH] Cari catatan di vault berdasarkan kata kunci judul/isi, saringan tag (misal: 'akuntansi'), atau saringan kategori direktori (misal: '10-Rekayasa-ERP' atau 'backend').

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": "vault_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagNo
queryNo
categoryNo
vault_pathNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden. The '[FAST VAULT SEARCH]' marker hints at lightweight performance and 'Cari' implies a read, but nothing states matching semantics (substring? case-sensitive?), result limits, pagination, or what happens when all filters are empty. For a zero-annotation tool this leaves significant gaps.

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?

Two short lines, front-loaded with the tool's identity and then the searchable dimensions. The inline examples earn their space by clarifying expected value formats. The bracketed '[FAST VAULT SEARCH]' prefix is slightly gimmicky but not wasteful.

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

Completeness2/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-value explanation is not required. Against that, the tool has four parameters with zero schema coverage, no annotations, and a completely undocumented vault_path, plus undefined filter-combination and result-size behavior — an agent could call it but could not predict what it gets back for ambiguous inputs.

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 0%, so the description must compensate and it does so for three of four parameters: query is scoped to title/content, tag is described as a filter with a sample value, and category is described as a directory filter with two sample values. The fourth parameter, vault_path, is never mentioned, and the interaction between filters (AND vs OR) is undefined.

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 states a specific verb and resource ('Cari catatan di vault') and enumerates the three matching modes: title/content keyword, tag filter, and directory-category filter. It is unmistakably a search tool and thus clearly separable from siblings like vault_lint_note or vault_scaffold_note, though it never names or contrasts those alternatives explicitly.

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 through the three filtering modes and concrete value examples ('akuntansi', '10-Rekayasa-ERP', 'backend'), which helps an agent pick the right filter. However, there is no statement of when to prefer this over the graph/backlink siblings, no note on combining filters, and no when-not-to-use guidance.

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