ragnarok
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RAGNAROK_HOME | No | Set RAGNAROK_HOME to use a different home folder. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Search the user's Obsidian vaults (). When a prompt continues or resembles earlier work but does not name the project, call find_projects first, then list_project on the best match. Use search for facts, open_note to read a note, and find_by_jira for Jira keys. Results hold note paths; cite them. A result can be unrelated: read the text before you use it.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| searchB | Hybrid search (meaning and keywords) over the vault notes. Returns notes, each with its best section. |
| find_projectsB | Find the earlier projects that a prompt continues or resembles, ranked by their matching notes. Each project has its slug, vault, folder, description, stage, state, next action and matching notes. |
| list_projectC | All notes of a project in any folder, with type, status and description, with stage, state, next action. |
| open_projectsA | The projects that are open, grouped by the state in their SUMMARY.md, newest update first. states defaults to in-progress and paused; the other values are done, superseded and abandoned. Each project has its slug, vault, folder, description, stage, state, gate, updated date and next action. |
| open_noteA | The text of a note (or of one section, by heading), its frontmatter, links and backlinks. |
| find_by_jiraC | The notes that contain a Jira key, for example ABC-123. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
The three project tools overlap heavily: find_projects and open_projects both return the same project shape (slug, vault, folder, description, stage, state, next action), differing only in ranking vs. state filter, so an agent can easily pick the wrong one. 'open_projects' also sounds like it opens something but actually lists, which blurs the line with open_note, and search vs. find_by_jira can both plausibly surface notes by key.
All names are snake_case, but the verb vocabulary is inconsistent: search, find_*, list_*, open_* are mixed, and 'open' means two different things (list projects vs. read note text). Readable, but not a predictable verb_noun pattern.
Six tools is well-scoped for a read-oriented notes vault: discovery (search, find_projects, find_by_jira), project views (open_projects, list_project), and retrieval (open_note). Each tool has a job and nothing looks padded.
The surface is entirely read-only: there is no way to create, append, or update a note, change project state, or move a note between stages, which are natural lifecycle operations for this domain. There is also no tool to enumerate vaults/folders or browse structure, so agents must reach everything through search filters.