Skip to main content
Glama

search_notes

Find relevant notes by keyword, exact phrase, or meaning and return ranked excerpts; filter by note, folder, tag, or date.

Instructions

Search notes: hybrid (keyword + meaning) by default. Returns ranked excerpts, not whole notes.

  • Use type="text" for an exact identifier, filename, code symbol or quoted phrase; "hybrid" for questions and topics.

  • READ THE SECTION, NOT THE NOTE. A hit's section is the heading its excerpt came from — pass that string to get_note's section to get that part alone. If a long hit has no section, get_note with limit:1000 returns its headings outline; pick one and re-read with section. For prose without headings, a hit's excerpt_offset goes to get_note as offset.

  • A hit is a candidate, not an answer. relevance is relative to the best hit in this response, so the top result always reads 1.0 — an ordering, not a verdict; best_score is that hit's own raw similarity. matched_by says which arms found it: semantic_score alone means "about something similar", never that it confirms your question. Quote the excerpt or open the note — a score is never evidence. exact:true means the query occurs verbatim in that note; text_tier of "or" or "substring" means the strict words missed and a looser pass filled in — recall, not confirmation.

  • A long note such as a book comes back as one hit with one excerpt. To find more places in it, search again with its note_id: results are then places inside that note, best first.

  • Dates here filter, they do not rank. For "what changed lately" use list_notes, which sorts by recency; it is also how you browse by folder or tag, since a query is required here.

  • has_more with next_offset pages the results.

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": {
      "query": "<query>"
    },
    "name": "search_notes"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagNoRestrict to notes with this tag
typeNo"hybrid" fuses keyword and meaning-based matching and is the right default; "text" is keyword-only and exact; "semantic" is meaning-onlyhybrid
limitNoHits per page. Prefer has_more with offset over asking for one large page
queryYesWhat to look for: words or a question for hybrid/semantic, an exact identifier, path or phrase for type "text"
offsetNoSkip this many hits — with has_more in the response, how you read past the first page
rerankNoSet false to skip the cross-encoder and answer from the fused order — several times faster, and not measurably worse. Applies to type "hybrid" only: text and semantic never rerank, and this flag changes nothing there
explainNoInclude raw per-arm scores and created_at for debugging ranking
note_idNoSearch inside this one note: results are places in it, best first, instead of one hit per note. Not combinable with folder, tag or date filters
folder_idNoRestrict to notes in this folder itself, not its subfolders
folder_pathNoSame restriction by path (e.g. "Projects/Kybase") instead of UUID — that folder itself, not its subfolders
created_afterNoISO timestamp — only notes created at or after this
updated_afterNoISO timestamp — only notes whose own content actually changed at or after this
created_beforeNoISO timestamp — only notes created at or before this
updated_beforeNoISO timestamp — only notes whose own content actually changed at or before this

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.3.1
    • changedInput schema / properties / folder_id / description
      Previous value: -"Restrict to notes in this folder"New value: +"Restrict to notes in this folder itself, not its subfolders"
    • removedInput schema / properties / folder_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 / limit / description
      Added value: +"Hits per page. Prefer has_more with offset over asking for one large page"
    • addedInput schema / properties / note_id
      Added value: +{
      +  "description": "Search inside this one note: results are places in it, best first, instead of one hit per note. Not combinable with folder, tag or date filters",
      +  "format": "uuid",
      +  "type": "string"
      +}
    • addedInput schema / properties / query / description
      Added value: +"What to look for: words or a question for hybrid/semantic, an exact identifier, path or phrase for type \"text\""
    • changedInput schema / properties / rerank / description
      Previous value: -"Set false to skip the cross-encoder and answer from the fused order — several times faster, and not measurably worse"New value: +"Set false to skip the cross-encoder and answer from the fused order — several times faster, and not measurably worse. Applies to type \"hybrid\" only: text and semantic never rerank, and this flag changes nothing there"
    • addedInput schema / properties / type / description
      Added value: +"\"hybrid\" fuses keyword and meaning-based matching and is the right default; \"text\" is keyword-only and exact; \"semantic\" is meaning-only"
  2. First observedv1.3.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it does: it discloses that relevance is normalized to the top hit (always 1.0) and is an ordering not a verdict, what best_score/matched_by/exact/text_tier actually mean, that long notes collapse to one hit, that dates filter and do not rank, and that has_more/next_offset paginate. These are non-obvious failure modes an agent would otherwise misread as confirmation.

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 one-line definition and the mode rule, then organized into bullets that each address a distinct decision. It is dense and longer than most definitions, but nearly every clause prevents a concrete misuse; a small amount of the ranking-metric explanation could be tightened.

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?

With 14 parameters, no annotations, and no output schema, the description compensates by documenting the response fields (relevance, best_score, matched_by, exact, text_tier, section, excerpt_offset, has_more) and the paging contract. An agent has everything needed to call it and interpret what comes back correctly.

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 coverage is 100%, so the baseline is 3, but the description adds genuine interpretation beyond the schema: note_id turns results into places-inside-a-note and is not combinable with folder/tag/date filters, dates do not affect ranking, and section/offset are meant to be forwarded to get_note. Only gap is the naming drift between the schema's `offset` and the description's `next_offset`, which could momentarily confuse pagination.

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?

Opens with a specific verb+resource ("Search notes") and immediately states the default mode (hybrid) and the return shape ("ranked excerpts, not whole notes"). That return-shape statement alone distinguishes it from get_note (whole notes) and list_notes (browsing), so an agent can pick correctly without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit mode-selection rules (text for identifiers/filenames/quoted phrases, hybrid for questions and topics) and an explicit alternative for a different need ("For 'what changed lately' use list_notes... it is also how you browse by folder or tag, since a query is required here"). It also prescribes a follow-up workflow (read the section, not the note; pass section/offset to get_note) rather than leaving it to inference.

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