Skip to main content
Glama

Search notes

search_notes
Read-onlyIdempotent

Search the user's notes by keyword or tag, including the ones in a collection. Matches the words in the text, not the meaning, so try another wording if nothing is found. Not for books, articles or podcasts themselves (their titles and authors), or for drafts.

Input Schema

NameRequiredDescriptionDefault
queryYesKeyword or tag to search for

Output Schema

NameRequiredDescriptionDefault
itemsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: matching is lexical rather than semantic, so a miss may be a wording problem rather than an absence, and collection-contained notes are in scope. Result limits and ordering are left to the output schema.

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?

Three short sentences: capability and scope first, then matching semantics, then exclusions. No filler, and the most decision-relevant information is front-loaded.

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 one-parameter read-only search with an output schema present, the definition covers what to search, what is included, how matching works, and what to exclude. Missing only result-set behavior such as limits or ordering, which the output schema plausibly covers, so the residual gap is minor.

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% and the single parameter is already documented as "Keyword or tag to search for". The description restates that and adds only the clarification that the term is matched against text words rather than meaning. Baseline 3 applies since the schema carries the parameter definition.

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?

States a specific verb and resource ("Search the user's notes") plus the matching dimension ("by keyword or tag"), and explicitly delimits scope: collection notes are included, while literature notes and drafts are not. An agent can separate it from search_literature_notes, search_drafts and search_collections without opening any 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?

Negative guidance is explicit and routes to the correct siblings: not for books/articles/podcasts themselves, and not for drafts. It also gives a recovery instruction ("try another wording if nothing is found"). It stops short of naming the alternative tools outright, so routing still requires a small inference.

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