Skip to main content
Glama

wb_vault

Search and read archived Obsidian markdown notes stored in cloud. Access years of historical thinking via list, search, and read commands.

Instructions

vault 云档只读域(P1 · dt_iy2eek):vault list/search/read 命令族,检索与读取 Obsidian 主库上云 md(COS vault-store 桶 obsidian/ 前缀 + vault_files 索引,刘总 5 年历史思考)。示例:vault search 精力 → vault read 。只读安全,readonly profile 可见。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNo命令参数数组(推荐,长文安全):如 ["note","add","这里是500字正文,含空格换行都不会被切碎","#工作笔记"]。数组元素原样作为 argv 传给 wb-cli,不按空白切分。command 仍需传(可传命令串本身),实际执行以 args 为准。
commandYeswb-cli 命令串(不含 wb-cli 前缀),如 "t todo"、"todo list --open"、"dev-task show dt_xxx"。与 args 二选一:传了 args 时 args 优先。各域允许的首词见 tool description。
confirmNo写操作必传 true(安全门)。判定为写操作的命令(add/done/edit/del/stage/item 等)缺 confirm 会被拒绝。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv5.10.1

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 safety burden and does so by explicitly stating 'read-only safe' and 'readonly profile'. It also discloses the backing store and index, which helps set expectations about data scope. It omits return/output details, but for a read-only lookup tool this is acceptable.

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 compact and front-loaded with the key identity and restrictions. Some incidental context (P1, dt_iy2eek, 'Liu's 5-year history') adds flavor but is not wasteful enough to drop the score.

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 read-only CLI-family wrapper, it covers the essential context: allowed commands, safety, data source, and a usage example. It lacks an explicit statement about not using write-oriented confirm, but the read-only framing makes that inference straightforward.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds the allowed first-words for the command parameter ('vault list/search/read') plus concrete invocation examples. This is meaningful beyond the generic schema text.

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 names a specific verb/domain ('vault list/search/read command family'), the resource (Obsidian cloud md), and labels it a read-only domain, which clearly separates it from the sibling wb-* tools. The example command chain further anchors what the tool does.

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

Usage Guidelines4/5

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

It clearly scopes usage to vault list/search/read and marks the tool as read-only, so an agent knows when it applies. It does not name sibling alternatives or explicit when-not-to-use conditions, but the command-family restriction is a clear contextual guide.

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