Obsidian MCP (pgvector + Ollama, self-hosted)

Recent notes

get_recent

Read-onlyIdempotent

Retrieve recently modified notes in newest-first order, filtered by folder, tags, frontmatter, or time range, with optional content-change ordering.

Instructions

Get recently modified notes, newest first.

Each line shows the note's modification time in UTC, as "YYYY-MM-DD HH:MM UTC".

Notes whose content changed since a point in time: order_by="content_changed" with since. File mtime (the default order) also moves when a file is touched or re-synced without a content change; content_changed moves only when the indexed content hash changes, and each line is then labelled changed. For an exact list of creations, edits, moves and deletions since a stored cursor, see get_changes.

Args: limit: Number of recent notes to return (default 20). folder: Optional folder prefix to filter (e.g. "Projects/"). tags: Optional list of tag names; only notes carrying ALL listed tags match (e.g. ["meeting"]). frontmatter: Optional dict of frontmatter key/value pairs; strict type match (e.g. {"status": "active"}). since: Optional UTC lower bound, inclusive: YYYY-MM-DD (that whole UTC day) or an ISO 8601 datetime with Z or ±HH:MM (no offset is refused). until: Optional UTC upper bound, exclusive; a date includes that whole day. order_by: "mtime" (default) or "content_changed"; the bounds apply to it. cursor: The more: cursor=… value from the previous page of the same call. When any of since/until/order_by/cursor is given, a full page ends with that footer.

Input Schema

Name	Required	Description	Default
`tags`	No
`limit`	No
`since`	No
`until`	No
`cursor`	No
`folder`	No
`order_by`	No
`frontmatter`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.10.0Oct 31, 2026

addedInput schema / properties / cursor

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Cursor"
+}

addedInput schema / properties / order_by

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Order By"
+}

addedInput schema / properties / since

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Since"
+}

addedInput schema / properties / until

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Until"
+}

Changed1 schema field changedv0.8.2Sep 24, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedMay 17, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses return-line formatting with UTC timestamps, the mtime versus content_changed behavioral difference, pagination footer behavior, and strict date parsing rules. These details materially help an agent predict what the tool returns and how filtering behaves.

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?

The description is dense but front-loaded, opening with the core behavior before elaborating on ordering and arguments. Given eight parameters and zero schema description coverage, every section carries useful information without obvious repetition.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is moderately complex with eight optional parameters, and the description covers all of them plus ordering, pagination, and timestamp semantics. With an output schema present, return values do not need fuller explanation, and nothing needed for correct invocation is missing.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 0%, the description documents all eight parameters with meaning, defaults, examples, and edge cases. It explains inclusive since, exclusive until, strict frontmatter type matching, ALL-tags matching, and cursor reuse semantics.

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 states a specific verb and resource: 'Get recently modified notes, newest first.' It also explicitly distinguishes the default mtime ordering from content_changed ordering and routes exact creation/edit/move/deletion tracking to get_changes.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance for content_changed versus the default mtime order, including the caveat that file mtime moves on touch or re-sync without content changes. It also names the alternative tool get_changes for an exact event list since a stored cursor.

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