Skip to main content
Glama

get_note

Retrieve full note content by ID or forgiving title match, with windowing for large notes, section extraction, and optional wikilink resolution.

Instructions

Get full note content by id or title. Title matching is case-insensitive and forgiving: an exact match wins, otherwise it falls back to prefix then substring, so a unique partial title resolves. An ambiguous title returns the candidate list (id + title) to retry with. Large notes are windowed: content is capped at 20000 chars by default (see limit/offset) — check content_truncated and content_total_length in the response, and pass next_offset back as offset to fetch the rest. Every response carries headings — the H1–H3 outline with character offsets, so a truncated note still shows what is in the part you did not get. Jump there with that offset, or name it in section to get that heading and its body alone — with section, headings narrows to that section's own subheadings too (offsets re-based to the section's own start, matching offset/limit's meaning in that mode), not the whole note's. Pass resolve_links: true to also resolve [[wikilinks]] inside it one level deep — use when you need a note's linked context without extra round-trips. Each linked note comes back as id/title/folder_path only by default; pass include_content:true for the full text of each (expensive if the note links to many others), capped at 4000 chars — call get_note on a specific id for its full text. updated_at moves on any stored change, including another note's rename rewriting a [[link]] to this one — pass it back as expected_updated_at on a write. content_updated_at only moves when THIS note's own title/content/folder/tags were actually edited — that's the one that answers "did anyone really touch this". Unresolved links (targets not found) are listed separately.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
limitNoMax characters of content to return
titleNo
offsetNoCharacter offset into content to start from
sectionNoReturn only this section (heading text or slug, case-insensitive) and its body
resolve_linksNoAlso resolve [[wikilinks]] inside the note one level deep
include_contentNoWith resolve_links: include full text of linked notes, not just id/title/folder_path

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so extensively. It discloses windowing behavior and the content_truncated/content_total_length flags, how headings behave when notes are truncated, section offset re-basing, one-level-deep wikilink resolution, the 4000-char cap on included linked-note content, and the subtle difference between updated_at and content_updated_at. No behavioral surprises are left for the agent to discover at call time.

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?

The description is long, but nearly every sentence carries functional information that is not available anywhere else since there are no annotations and no output schema. It is front-loaded with the core purpose and moves logically from retrieval to pagination, headings, sections, link resolution, and timestamps. It is not concise, but the length is justified by the tool's complexity; it loses a point only because a more scannable structure (e.g., shorter paragraphs or labeled behaviors) would help agent parsing.

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?

This is a complex tool with 7 parameters, zero required fields, no annotations, and no output schema, so the description must cover invocation behavior, return fields, and edge cases. It does: response fields like content_truncated, content_total_length, headings, next_offset, and unresolved links are all explained; pagination, section mode, link resolution, and timestamp semantics are fully covered. Nothing needed to call the tool correctly appears to be 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?

Schema coverage is 71%, and the description substantially compensates for the undocumented params (id, title) while adding meaning to the documented ones. It explains title matching fallbacks, the meaning of offset/limit in windowing and section mode, section selection semantics, resolve_links depth, and include_content tradeoffs. This goes well beyond the schema and makes parameter behavior predictable.

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 opening sentence states a specific verb and resource: 'Get full note content by id or title.' It immediately distinguishes the tool from list/search siblings by focusing on retrieving a single note's full content, and the rest of the description clarifies the nuanced retrieval semantics (title matching, windowing, sections). This is unambiguous and distinguishes the tool's role among the sibling tools.

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?

The description provides clear context for when to use advanced options: use resolve_links when 'you need a note's linked context without extra round-trips' and use section to fetch a heading and its body alone. It does not explicitly contrast this tool with sibling alternatives like list_notes or search_notes, but for a single-note fetch tool the intended use is well implied. The absence of explicit exclusions or alternative-tool routing keeps it from a 5.

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