Skip to main content
Glama

Search notes

search_notes
Read-only

Search the user's notes. Words are matched against the note's text, its tags, and the title, description and URL of any link saved with it; a word of three characters or fewer counts only as a whole word. The default mode ("auto") escalates only as far as it needs to: every word, then any word, then meaning — and the reply's matched field says which one answered, so a relaxed or semantic result is never mistaken for an exact one. Pin the strategy with mode="keyword" (every word must appear; never widens), "semantic" (meaning only) or "hybrid" (both, fused). Source, date, photo and thread filters compose with the text query and tags. Filter by tag with tags, which is the right tool for a request like "my #bug notes". An empty result carries hints: what the collection actually contains and which query to try next — read them instead of guessing another wording. Bodies are omitted unless you pass full=true; complete imported source metadata is omitted with them. Compact notes come back as { id, label, user_text, tags, source, root_id, parent_id, is_thread_head, thread_count, updated_at, … }. user_text is only text deliberately written by the user; imported page or social-post copy is source metadata. label names the note even when it has no title — use it when showing a note to a human. updated_at is what you pass back as if_updated_at when you write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNoInclude each note’s body. Default false — leave it off for wide searches.
modeNoDefault auto: exact first, widening only if that finds nothing. Pin to keyword for strictly deterministic matching, or to semantic/hybrid to force meaning-based retrieval.
tagsNoOnly notes carrying ALL of these tags. Case-insensitive, no leading #. A tag also covers everything under it: "notemcp" matches a note tagged "notemcp/bug/share", so filter by the broadest level that answers the question and narrow only if you get too much back. Matching is from the start of the path: "main" does not match "features/main".
limitNoMax results (default 20, max 100)
queryNoWords to match. Omit to use filters alone.
offsetNoSkip this many results, for paging
root_idNoReturn the thread head and continuations belonging to this root note.
archivedNoDefault exclude.
has_photosNoWhether the note has a body attachment or a retrievable link-preview thumbnail.
has_sourceNoWhether imported URL/title/description/image source metadata exists.
source_typeNoExact capture/source type, such as "share" or "agent".
created_afterNoCreated at or after this timestamp (inclusive).
source_domainNoExact source hostname, case-insensitive and ignoring a leading www., such as "instagram.com".
updated_afterNoUpdated at or after this timestamp (inclusive).
created_beforeNoCreated before this timestamp (exclusive).
updated_beforeNoUpdated before this timestamp (exclusive).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
hintsNoPresent only when notes is empty: concrete next queries worth trying.
notesNo
noticeNoPresent when the answer is not what was asked for — a fallback or degradation.
matchedNoWhich strategy produced these notes. "any_term" means the every-word search found nothing and this is a relaxed any-word fallback.
withheldNoHow many further notes matched but were not read, because this connection reads only part of a large collection. Present only when greater than zero. Those notes still exist and are searchable inside NoteMCP — they are invisible to this connection, not deleted. Treat the answer as incomplete and say so, rather than reporting that the user has nothing on the subject.
capabilitiesNoPresent only when a retrieval capability is unavailable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / withheld / description
      Previous value: -"How many further notes matched but sit outside the account's free plan, which limits how many notes a connected assistant may read. Present only when greater than zero. Those notes still exist and are searchable inside NoteMCP — they are invisible to this connection, not deleted. Treat the answer as incomplete and say so, rather than reporting that the user has nothing on the subject."New value: +"How many further notes matched but were not read, because this connection reads only part of a large collection. Present only when greater than zero. Those notes still exist and are searchable inside NoteMCP — they are invisible to this connection, not deleted. Treat the answer as incomplete and say so, rather than reporting that the user has nothing on the subject."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare read-only and non-destructive; the description carries the real behavioral load: whole-word treatment for words of three characters or fewer, the auto escalation order (every word → any word → meaning), the matched field's role in distinguishing exact from relaxed results, hints on empty results, and body/source-metadata omission unless full=true. It also clarifies output-field semantics such as user_text versus imported source copy and label as the human-facing name. There is no contradiction with the annotations.

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 long, but the tool has 16 parameters and genuinely complex semantics, so the length is earned. It is front-loaded — purpose and matching rules first, response-shape details last — and every sentence addresses a distinct concern: matching, modes, filters, empty-result protocol, body omission, and output-field meanings. No filler or repetition.

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?

For a high-complexity tool this is complete: matching semantics, mode behavior, filter composability, the empty-result protocol, body omission behavior, and key output-field meanings (matched, hints, user_text, label, updated_at) are all disclosed. Since an output schema exists, the description goes beyond what is strictly required rather than omitting anything the agent needs to select or invoke the tool correctly.

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?

Despite 100% schema coverage (baseline 3), the description adds substantial meaning the schema cannot convey: hierarchical tag matching ('notemcp' matches 'notemcp/bug/share'), prefix-from-start matching rules, the behavioral escalation of mode rather than its enum values alone, and when full=true materially changes results. These are semantics an agent could not infer from parameter names or schema descriptions.

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 and resource — 'Search the user's notes' — and immediately scopes the search surface: note text, tags, and the title, description and URL of saved links. Among siblings like get_note and list_recent_notes it is unmistakable which tool this is and what it operates on. The description goes well beyond restating the name.

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?

Provides explicit tactical guidance: tags is called out as 'the right tool for a request like my #bug notes', mode pinning is explained for keyword/semantic/hybrid strategies, and empty results direct the agent to read hints instead of guessing another wording. What is missing is explicit when-not guidance against sibling tools (e.g., when to prefer get_note or list_recent_notes), so it stops just short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources