Skip to main content
Glama
Sign In
Kybase

Kybase

by Kyrzin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_note

Read a note by ID or title, page through long content, jump to a heading section, and optionally resolve linked notes for context.

Instructions

Read one note, by id or title.

  • Long notes come back windowed — 20000 chars by default: check content_truncated and pass next_offset back as offset for the rest. A windowed reply carries headings — the H1–H3 outline with character offsets — so name one in section to get that heading and its body alone instead of paging through the note.

  • resolve_links:true also returns the notes this one links to, id/title only unless you add include_content:true, whose text is capped at 4000 chars — call get_note on an id for the whole of one. Targets that match no note are listed as unresolved.

  • Pass the updated_at you read back as expected_updated_at when you write. content_updated_at is the one that moves only on a real edit to this note: a rename elsewhere rewriting a [[link]] inside it touches updated_at but not that.

Input Schema

NameRequiredDescriptionDefault
idNoThe note's UUID. Live notes only — a trashed note is not found until restore_note brings it back
limitNoMax characters of content to return
titleNoAlternative to id: exact match first, then unique prefix, then unique substring. An ambiguous title comes back as the candidate list to retry with
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. Changed4 schema fields changedv1.3.1
    • addedInput schema / anyOf
      Added value: +[
+  {
+    "required": [
+      "id"
+    ]
+  },
+  {
+    "required": [
+      "title"
+    ]
+  }
+]
    • addedInput schema / properties / id / description
      Added value: +"The note's UUID. Live notes only — a trashed note is not found until restore_note brings it back"
    • removedInput schema / properties / id / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
    • addedInput schema / properties / title / description
      Added value: +"Alternative to id: exact match first, then unique prefix, then unique substring. An ambiguous title comes back as the candidate list to retry with"
  2. First observedv1.3.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description still discloses non-obvious behavior: the 20000-character default window, content_truncated/next_offset paging, the headings outline, resolve_links depth and 4000-character cap, unresolved targets, and the distinction between updated_at and content_updated_at. It does not cover permissions or rate limits, but for a read tool this is strong behavioral context.

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 front-loaded with a one-line purpose and then uses focused bullets for pagination, sections, link resolution, and timestamps. It is dense but every bullet addresses behavior that affects invocation.

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?

There is no output schema, but the description explains the key return-control fields and truncation/link-resolution behavior. Some return-shape and error details are left to the schema or inference, so it is strong but not fully complete.

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 100%, so the baseline is 3; the description adds useful relationships such as passing next_offset back as offset, using headings to choose section, and the include_content cap with resolve_links. It also references expected_updated_at, a write-side parameter not present in this schema, which is cross-tool context rather than local parameter documentation.

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 gives a specific verb and resource ('Read one note') and restricts scope to id or title, clearly separating it from list_notes and search_notes. An agent can identify the tool's purpose without opening the schema.

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?

It explains operational choices for paging versus section retrieval and for including linked-note content. However, it does not explicitly route between sibling retrieval tools such as search_notes or list_notes when the id or exact title is unknown.

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