NoteDiscovery MCP Server

search_notes

Search all notes by keywords, phrases, or natural language, optionally within a folder, and get matching notes with snippets showing where matches occur.

Instructions

Search through all notes using full-text search. Returns matching notes with snippets showing where the match was found. Use this to find notes by content, keywords, or phrases.

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

Name	Required	Description
`limit`	No	Maximum number of results to return. Useful for large vaults. If not specified, returns all matches.
`query`	Yes	Search query. Can be keywords, phrases, or natural language.
`folder`	No	Only include notes under this folder (e.g., 'projects/2024').
`offset`	No	Number of results to skip. Use with limit for pagination.
`recursive`	No	With folder, also include subfolders. Defaults to true.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.34.1Nov 13, 2026

addedInput schema / properties / folder

Added value: +{
+  "description": "Only include notes under this folder (e.g., 'projects/2024').",
+  "type": "string"
+}

addedInput schema / properties / recursive

Added value: +{
+  "description": "With folder, also include subfolders. Defaults to true.",
+  "type": "boolean"
+}

First observedv0.1.0Jun 24, 2026

TDQS

A3.5/5.0

Behavior3/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 contribute the return shape (matching notes with snippets showing where the match was found), which is real value given there is no output schema. It says nothing about permissions, result ordering, performance on large vaults, or pagination behavior — the latter is only covered indirectly by the schema's limit/offset fields.

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?

Three short sentences, front-loaded with the core action and return shape, with no filler. Minor waste in repeating the search-by-content idea in the third sentence.

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?

For a 5-parameter, well-described schema with no output schema, the description covers purpose, mechanism, and return format — enough to call it correctly. It is only thin on scoping nuance (folder narrows results despite "all notes") and on when a different sibling tool is preferable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter is already documented in-schema and the baseline is 3. The description adds only the notion of full-text matching plus snippets; it does not clarify how multi-word phrases are parsed or that folder scoping narrows the "all notes" claim, which conflicts slightly with the opening line.

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?

States a specific verb (search) and resource (notes) plus the mechanism (full-text search) and return shape (matching notes with snippets). It implicitly separates itself from get_notes_by_tag, get_recent_notes, and list_notes by framing itself as content/keyword lookup, but never names those siblings explicitly.

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

Usage Guidelines3/5

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

"Use this to find notes by content, keywords, or phrases" gives an implied use case but no exclusions or alternatives — an agent comparing this to get_notes_by_tag (tag-based) or list_notes (enumeration) gets no routing help. The guidance is adequate but leaves the choice to inference.

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