Skip to main content
Glama

Search notes

search_notes
Read-only

Search all notes for any text, optionally using regex or restricting to a folder, and get paths, line numbers, and matching lines.

Instructions

Full-text search across all notes. Default is case-insensitive substring matching; set regex=true to treat query as a regular expression. Returns path, line number and the matching line, capped at 50 hits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesText to search for
regexNoTreat query as a regular expression
folderNoOptional subfolder to restrict the search

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, and the description adds substantial behavioral detail beyond that: default case-insensitive substring matching, regex opt-in, the return format (path, line number, matching line), and the 50-hit cap. This gives the agent an accurate expectation of what the tool does and returns.

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?

Two sentences, no wasted words. The core purpose is front-loaded, and the behavioral details follow naturally. Every sentence earns its place.

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?

Given no output schema, the description responsibly explains the return shape and limit. It covers search scope, matching semantics, regex behavior, folder restriction, and result contents. An agent has enough to invoke this tool correctly without ambiguity.

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. The description goes further by explaining the default matching behavior ('case-insensitive substring matching') and the implication that regex is opt-in, which adds meaning beyond the schema's brief parameter descriptions. Folder restriction is not expanded, but the overall parameter semantics are well supported.

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 description opens with 'Full-text search across all notes', which names a specific verb and resource and clearly distinguishes it from sibling tools like list_notes or read_note. The mention of substring matching and regex further clarifies the exact operation.

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 clearly establishes when to use this tool: when you need to find matching content across notes, with optional folder restriction. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough that an agent can infer this is the content-search tool rather than a metadata or note-management tool.

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