Skip to main content
Glama
Sign In
vault-memory

vault-memory

by owrede
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

query_frontmatter

Read-onlyIdempotent

Filter Obsidian notes by YAML frontmatter properties to find entries matching equality, $in, $exists, or $contains conditions; combine multiple keys with AND.

Instructions

Filter notes by their YAML frontmatter. Supports equality, $in, $exists, $contains predicates. Multiple keys are AND-combined.

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": {
      "vault": "<vault>",
      "where": "<where>"
    },
    "name": "query_frontmatter"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
vaultYes
whereYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.0
    • changedInput schema / properties / where / additionalProperties / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  },
-  {
-    "properties": {
-      "$in": {
-        "items": {
-          "anyOf": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "number"
-            },
-            {
-              "type": "boolean"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "type": "array"
-      }
-    },
-    "required": [
-      "$in"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "$exists": {
-        "type": "boolean"
-      }
-    },
-    "required": [
-      "$exists"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "$contains": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "number"
-          },
-          {
-            "type": "boolean"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      }
-    },
-    "required": [
-      "$contains"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  },
+  {
+    "properties": {
+      "$in": {
+        "items": {
+          "type": [
+            "string",
+            "number",
+            "boolean",
+            "null"
+          ]
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "$in"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "$exists": {
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "$exists"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "$contains": {
+        "type": [
+          "string",
+          "number",
+          "boolean",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "$contains"
+    ],
+    "type": "object"
+  }
+]
  2. First observedv2.0.0-rc.5

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds the AND-combination behavior of multiple keys, which is genuinely useful, but says nothing about limits, result ordering, or behavior on unknown keys.

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?

Three tight sentences, each earning its place: purpose first, then predicate support, then combination semantics. Nothing redundant.

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?

For a nested-object query tool with no output schema and 0% schema coverage, the description covers the core filtering semantics but omits anything about the shape of results, how `limit` behaves, or what an empty/malformed `where` does. It is minimally sufficient rather than complete.

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 carry parameter meaning. It does explain the predicate operators ($in, $exists, $contains) and equality, plus the AND semantics of the complex `where` object, which is the hardest parameter. However, `vault` and `limit` (with its default and cap) receive no explanation at all.

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 specific verb and resource: 'Filter notes by their YAML frontmatter'. It is distinguishable from the search_* siblings in concept, but it never explicitly contrasts itself with search_text/search_semantic, so the division of labor is left implicit.

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?

There is no when-to-use guidance and no mention of alternatives, despite several plausible substitutes (search_text, search_semantic, search_hybrid, list_vaults) in the sibling set. The agent must infer that frontmatter-based filtering is the right choice.

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