hive

Overview Schema Source Related Servers Discussions Admin

Vault Search

vault_search

Read-onlyIdempotent

Search an Obsidian vault by full-text, ranked relevance, or recent changes. Filter results by scope, project, tags, type, status, or regex to locate the files you need.

Instructions

Search the vault: full-text, ranked, or recent changes.

Default mode: flat full-text search across all vault files. Ranked mode (ranked=True): results scored by relevance. Recent mode (since_days>0): files changed in the last N days. rank_by mode (rank_by != 'bm25'): lessons-only, ranked by usage.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Alias of `max_results` (#202). Prefer `max_results`. When both are given the tighter (smaller) cap wins; 0 = unset.
`query`	No	Text to search for (case-insensitive).
`regex`	No	Alias of `use_regex` (#151). Prefer `use_regex`. To narrow by location use `scope` / `project`, not `path_filter` / `path_prefix`.
`scope`	No	Restrict search to a scope (e.g. 'work', 'projects'). Empty = all.
`ranked`	No	Score results by relevance. Default False.
`project`	No	Filter to this project (recent mode only).
`rank_by`	No	Lesson ranking ('bm25' default keeps current behaviour; 'reinforcements', 'confidence', 'hybrid' filter to 90-lessons.md only and rank by usage signal).	bm25
`max_lines`	No	Maximum output lines. Default 500.
`use_regex`	No	Treat query as regex. Default False. (Use `use_regex`, not `regex` — `regex` is accepted as an alias.)
`since_days`	No	Show recent changes (0 = disabled). Default 0.
`tag_filter`	No	Only files that have this frontmatter tag.
`max_results`	No	Max result files. Default 10. Caps the file count in all modes (flat, ranked, recent); in flat/recent the cap is by path order (alphabetical) — use ranked=True for relevance order.
`type_filter`	No	Only files whose frontmatter type matches.
`status_filter`	No	Only files whose frontmatter status matches.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.41.1Jun 10, 2026

addedInput schema / properties / limit

Added value: +{
+  "default": 0,
+  "description": "Alias of `max_results` (#202). Prefer `max_results`. When\nboth are given the tighter (smaller) cap wins; 0 = unset.",
+  "type": "integer"
+}

changedInput schema / properties / max_results / description

Previous value: -"Max files when ranked. Default 10."New value: +"Max result files. Default 10. Caps the file count in\nall modes (flat, ranked, recent); in flat/recent the cap is by\npath order (alphabetical) — use ranked=True for relevance order."

Changed2 schema fields changedv1.23.0May 31, 2026

addedInput schema / properties / regex

Added value: +{
+  "default": false,
+  "description": "Alias of `use_regex` (#151). Prefer `use_regex`. To narrow\nby location use `scope` / `project`, not `path_filter` /\n`path_prefix`.",
+  "type": "boolean"
+}

changedInput schema / properties / use_regex / description

Previous value: -"Treat query as regex. Default False."New value: +"Treat query as regex. Default False. (Use `use_regex`,\nnot `regex` — `regex` is accepted as an alias.)"

Addedv1.21.0May 28, 2026
Removedv1.13.0May 20, 2026
Changed1 schema field changedv1.4.2May 2, 2026
- addedInput schema / properties / scope
```
Added value: +{
+  "default": "",
+  "type": "string"
+}
```
First observedv1.11.0Mar 10, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds mode-specific behavior (e.g., rank_by != 'bm25' limits to lessons-only) but does not disclose other behavioral traits like performance, pagination details, or the interaction of aliases. Given the annotations, this is adequate but not rich.

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 description is concise, front-loaded with the core purpose, and uses a compact bullet-like structure to list modes. Every line adds value, and there is no fluff. It could be slightly more structured, but it is efficient and readable.

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?

Given the presence of an output schema and 100% schema coverage, the description does not need to explain return values or every parameter. It covers the primary modes and their key parameters, which is sufficient for an agent to understand how to invoke the tool correctly for common use cases. It does not mention all filters (tag, status, type), but those are self-explanatory in the schema.

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?

With 100% schema coverage, the baseline is 3. The description adds meaningful semantics by explaining the effects of ranked, since_days, and rank_by parameters, including that rank_by != 'bm25' restricts to lessons-only and ranks by usage. This goes beyond the schema's property descriptions and clarifies intended usage.

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 clearly states 'Search the vault' and enumerates three distinct modes (flat, ranked, recent) plus a rank_by variant, giving a specific verb and resource with mode distinctions. However, it does not explicitly differentiate from sibling tools like vault_query, so it doesn't fully separate itself from alternatives.

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 provides usage guidance for its own modes (when to use ranked, recent, rank_by) but never mentions when to use this tool versus other vault-related tools like vault_query or vault_list. There is no explicit 'use this for X, use that for Y' guidance, so the tool-level selection context is missing.

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

Deploy Server