Skip to main content
Glama
Sign In
ragnarok

ragnarok

by freyr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

open_note

Reads an Obsidian note by path, returning its text, frontmatter, links, and backlinks; use heading or outline options to retrieve long notes or specific sections.

Instructions

The text of a note (or of one section, by heading), its frontmatter, links and backlinks.

    outline=true gives the sections (heading path, words, first sentence) instead of the text. A note of more
    than 4000 words gives the outline unless outline=false; then open the section you need by heading, as the
    last heading or the full path such as "Results > Inferences".
    Credentials in the text are replaced with [REDACTED]. Private notes are refused.

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": {
      "path": "<path>"
    },
    "name": "open_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes
headingNo
outlineNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.1
    • addedInput schema / properties / outline
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Outline"
+}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "open_noteDictOutput",
+  "type": "object"
+}
  2. First observedv1.0.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the automatic outline fallback above 4000 words, that credentials are replaced with [REDACTED], and that private notes are refused. These are non-obvious data-handling, security and truncation behaviors an agent could not learn from the schema.

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?

Front-loaded with the return content, then the outline behavior and the large-note rule, with no filler sentences. The first line reads as a fragment rather than a statement of action, which is a minor structural weakness but costs no clarity.

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?

An output schema exists, so return values need not be explained, and the description still covers parameter behavior, the 4000-word cutoff, redaction and refusal. It omits error behavior for a nonexistent path or heading, which is the only notable gap for a three-parameter read tool.

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 description coverage is 0%, so the description must supply meaning, and it explains both optional parameters: outline toggles between text and section summaries, and heading accepts a last heading or a full 'Results > Inferences' style path. Only 'path' itself is left implicit, which is reasonable given its name.

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?

The opening states precisely what is returned: the note text (or one section by heading), frontmatter, links and backlinks. The resource and scope are unambiguous, though it is phrased as a noun clause rather than a verb ('returns the text of...'), and it never contrasts itself with siblings like search or find_projects.

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?

Guidance is explicit for the two optional parameters: use outline=true to get sections, and for notes over 4000 words open the needed section by heading using the last heading or a full path like 'Results > Inferences'. What is missing is when to choose this tool over the search/find siblings, so selection among tools is left to inference.

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