duckuments-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DUCKUMENTS_LOG | No | Log level: error/warn/info/debug (stderr only) | info |
| OBSIDIAN_API_KEY | Yes | Plugin Bearer key (required) | |
| OBSIDIAN_API_URL | No | Plugin base URL | http://127.0.0.1:27123 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_noteA | Read a note from the vault by its vault-relative path (e.g. 'Dev days/foo.md'). |
| get_activeA | Read the note currently open in Obsidian. |
| list_notesA | List files/folders in the vault, or inside a given folder (e.g. 'Dev days/'). |
| update_noteA | Create or overwrite a note at the given path with the given markdown (PUT). |
| patch_noteB | Insert content relative to an existing heading in a note (PATCH). |
| searchB | Plain-text search across the vault. |
| commitA | Commit the already-staged files in the project repo with your own git identity. Does NOT stage and does NOT push. |
| initA | Read your roles note (Templates/Claude/Implementing Role.md) and write it into the project's CLAUDE.md, inside a managed block. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| fill_out | Read the note and fill it out: answer its questions, write the text/suggestions it asks for, and find and fix any conflicts inside it. Only read and edit the note — do NOT change any project code. Typically used to explore a project's source or answer questions about it. |
| work_on | Read the note and implement the points it describes into the project code. Typically used for plans that are ready to be built. |
| plan_for | Review the note and the project, then plan how to implement the note's tasks within the project. Only plan and edit the note's content — do NOT change any project code. Typically used for planning notes. |
| debug | Read the note, identify and fix the issue based on the problem and information described in it, then state what the problem was and how you resolved it. Typically used for debugging. |
| summarize | Write a non-technical, client-ready summary of the changes into the active note's Summerize section. |
| init | Write your Obsidian roles note into the project's CLAUDE.md. |
| commit | Commit your current changes with your own git identity, without pushing. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Most tools target clearly distinct actions: reading by path, reading the active note, listing, searching, overwriting, and patching. The only mild risk is update_note vs patch_note, but their descriptions make the full-overwrite vs heading-relative-insert distinction clear.
Several tools follow a verb_noun pattern (get_note, list_notes, update_note, patch_note), but get_active, search, commit, and init deviate by using bare verbs or verb-adjective forms. The pattern is readable but not consistently applied.
Eight tools is a reasonable size for an Obsidian/document-management server. Each tool contributes a distinct operation, and the count feels neither bloated nor sparse.
Core note reading, writing, listing, and searching are covered, but there is no delete, move, rename, or folder-management operation. The commit tool also assumes staging was done externally, leaving a notable workflow gap.