Skip to main content
Glama

RelayLink

Search past messages

search_messages
Read-onlyIdempotent

Search this account's correspondence by words, and optionally by who wrote it, when, and what kind of statement it was. Answers "find Richard's feedback about onboarding", "why did we reject that pricing option", "what did I promise the client". Every hit says which field it matched — a decision, a rejected option, an open question, the sender's note — so a proposal is never reported as a decision, and a hit with something later on the same thread is marked, because a correction is the newest thing said rather than the best match. Reads only, and reaches nothing the user could not already open. Searches CORRESPONDENCE; notebook_find searches the user's own private notebook. get_package reads a hit in full and get_thread reads the conversation around it.

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": {
      "text": "<text>"
    },
    "name": "search_messages"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagNoNarrow to threads the user has tagged with this word — the user's own private label, from list_tags. Omit for every thread.
fromNoLimit to one person: their email address, or a contact name as the user says it. A name that matches two contacts is reported rather than guessed between.
kindNoLimit to one kind of statement: any (default) | decision | option | option-chosen | option-rejected | question | note | ask | assumption | message | brief | excerpt. "message" is the body the sender wrote; "brief" is the TL;DR and the background around it.any
textYesWhat to look for, in the user's own words — a half-remembered phrase is fine, and at least 3 characters. Matched on word stems against the sender's note, the ask, the TL;DR, the message itself, the brief, assumptions, options, decisions, open questions and excerpts, so "forking" finds "fork"; a misspelling gets one attempt against words this account actually uses, and the reply says which word was searched for. Ordered by how well each matches rather than by date.
limitNoHits per page (default 5, max 10). A ranked search puts the answer at the top; get_package reads one in full.
sinceNoOnly messages sent on or after this date (2026-09-01).
untilNoOnly messages sent on or before this date.
offsetNoSkip this many hits, most recent first (default 0). The reply says the offset of the next page.
projectNoNarrow to conversations filed under one notebook project, by name — the same projects notebook_find uses. Omit for every thread.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark it as read-only, idempotent, non-destructive, and closed-world, but the description adds important behavior: hits report which field matched, later thread activity marks a hit, and results are ranked by match quality rather than date. It also explains the typo fallback and the safety boundary that it reaches nothing the user could not already open.

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 front-loaded with the core purpose, then examples, then behavioral distinctions and alternatives. Despite being long, every sentence adds decision-relevant information and there is little waste.

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 nine-parameter search tool with no output schema, the description covers what it searches, how hits are marked and ranked, and which sibling tools to use for full reads or thread context. The schema fills in parameter details, so the combined definition is complete enough to invoke correctly.

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 the schema already documents all nine parameters thoroughly. The description adds useful framing around searching by words versus sender/date/kind, but it does not substantially deepen parameter meaning beyond what the schema fields already state.

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 this account's correspondence") and scopes it by optional fields. It explicitly distinguishes itself from notebook_find, get_package, and get_thread, so an agent can select it without inspecting siblings.

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?

Names concrete use cases ("find Richard's feedback about onboarding", "why did we reject that pricing option") and explicitly routes full-hit reading to get_package, thread reading to get_thread, and private notebook search to notebook_find. The alternatives and boundary conditions are clear.

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