Skip to main content
Glama

search_messages

Read-onlyIdempotent

Search message content across all chats — semantic + keyword. Use to find what was said: quotes, topics, info exchanged. Also finds captionless photos/screenshots by what they show or the words read from them: such a hit carries match_reason ('image' or 'attachment_text') and file_id — open that attachment. Pass direction, chat_kind or per_chat for an EXACT text search instead: who wrote it (outgoing = the owner), private chats or groups, one result per chat with the number of matches. That is the way to find the chat of a person by how the owner addresses them, e.g. query='Дима', direction='outgoing', chat_kind='dm', per_chat=true. For chats/threads themselves use search.threads; for files use search.files; for links use search.links.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum messages to return.
queryNoWhat to search for in message content.
channelNo'ai_panel' = search the workspace's AI-panel ("My AI") chats (owner/admin: all; a member: their own) by text; needs `query`. OMIT for the normal inbox.
date_toNoISO8601 date (YYYY-MM-DD) upper bound. OMIT to skip.
per_chatNoExact search only: one result per chat (its newest match) with `matches` = how many messages there matched. OMIT for every message.
chat_kindNoExact search only: 'dm' = private chats, 'group' = groups and channels. OMIT for both.
date_fromNoISO8601 date (YYYY-MM-DD) lower bound. OMIT to skip.
directionNoExact search only: 'outgoing' = messages the owner wrote, 'incoming' = messages others wrote. OMIT for both.
whole_wordNoExact search only: match the query as a whole word ('Дима' finds 'Привет, Дима!' but not 'Димасик'). OMIT to match any part of a word.
image_limitNoMaximum number of photo/screenshot rows in the results (0 to 50; 0 = no image rows). OMIT for the default: about a quarter of `limit`, at least 2, and more only when text hits leave slots unused. When given, it is a hard maximum. A value outside 0..50 is refused, never clamped.
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
image_min_scoreNoMinimum similarity (0 to 1) for photo/screenshot matches. Affects image hits only; text hits are unaffected. OMIT for the default (0.29 unless the deployment configures another). Image scores run lower than text scores: typically clear matches are about 0.40-0.50 and noise is usually below roughly 0.32. Raise it (e.g. 0.35) when photo hits are noisy; lower it (e.g. 0.25) to find weak matches such as scanned documents. A value outside 0..1 is refused, never clamped.
image_hub_marginNoHow far (0 to 1) an image match must stand above that image's own similarity to unrelated queries; this hides images that look close to every query. OMIT it: the default is tuned. Change it only when the results show a problem, and then lower it a little (e.g. 0.04) rather than 0, which turns the check off. A value outside 0..1 is refused, never clamped.
participant_nameNoFilter to messages involving this participant/contact name. OMIT to search across everyone (do NOT pass an empty string).
image_strong_scoreNoSimilarity bar (0 to 1) that decides WHERE photo/screenshot matches go. At or above it a photo is interleaved near the top of the results (after the first text hit); below it (but above `image_min_score`) it is listed after all text results. Affects image hits only. OMIT for the default (0.40 unless the deployment configures another): typically clear matches score about 0.40-0.50. If it is below `image_min_score`, `image_min_score` is used as the bar. Raise it (e.g. 0.45) to keep photos out of the top unless they are clearly relevant; lower it (e.g. 0.33) when the answer is probably a photo. A value outside 0..1 is refused, never clamped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / image_hub_margin
      Added value: +{
      +  "description": "How far (0 to 1) an image match must stand above that image's own similarity to unrelated queries; this hides images that look close to every query. OMIT it: the default is tuned. Change it only when the results show a problem, and then lower it a little (e.g. 0.04) rather than 0, which turns the check off. A value outside 0..1 is refused, never clamped.",
      +  "type": "number"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / image_limit
      Added value: +{
      +  "description": "Maximum number of photo/screenshot rows in the results (0 to 50; 0 = no image rows). OMIT for the default: about a quarter of `limit`, at least 2, and more only when text hits leave slots unused. When given, it is a hard maximum. A value outside 0..50 is refused, never clamped.",
      +  "type": "integer"
      +}
    • addedInput schema / properties / image_min_score
      Added value: +{
      +  "description": "Minimum similarity (0 to 1) for photo/screenshot matches. Affects image hits only; text hits are unaffected. OMIT for the default (0.29 unless the deployment configures another). Image scores run lower than text scores: typically clear matches are about 0.40-0.50 and noise is usually below roughly 0.32. Raise it (e.g. 0.35) when photo hits are noisy; lower it (e.g. 0.25) to find weak matches such as scanned documents. A value outside 0..1 is refused, never clamped.",
      +  "type": "number"
      +}
    • addedInput schema / properties / image_strong_score
      Added value: +{
      +  "description": "Similarity bar (0 to 1) that decides WHERE photo/screenshot matches go. At or above it a photo is interleaved near the top of the results (after the first text hit); below it (but above `image_min_score`) it is listed after all text results. Affects image hits only. OMIT for the default (0.40 unless the deployment configures another): typically clear matches score about 0.40-0.50. If it is below `image_min_score`, `image_min_score` is used as the bar. Raise it (e.g. 0.45) to keep photos out of the top unless they are clearly relevant; lower it (e.g. 0.33) when the answer is probably a photo. A value outside 0..1 is refused, never clamped.",
      +  "type": "number"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / channel
      Added value: +{
      +  "description": "'ai_panel' = search the workspace's AI-panel (\"My AI\") chats (owner/admin: all; a member: their own) by text; needs `query`. OMIT for the normal inbox.",
      +  "type": "string"
      +}
  4. Changed4 schema fields changed
    • addedInput schema / properties / chat_kind
      Added value: +{
      +  "description": "Exact search only: 'dm' = private chats, 'group' = groups and channels. OMIT for both.",
      +  "enum": [
      +    "dm",
      +    "group"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / direction
      Added value: +{
      +  "description": "Exact search only: 'outgoing' = messages the owner wrote, 'incoming' = messages others wrote. OMIT for both.",
      +  "enum": [
      +    "outgoing",
      +    "incoming"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / per_chat
      Added value: +{
      +  "description": "Exact search only: one result per chat (its newest match) with `matches` = how many messages there matched. OMIT for every message.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / whole_word
      Added value: +{
      +  "description": "Exact search only: match the query as a whole word ('Дима' finds 'Привет, Дима!' but not 'Димасик'). OMIT to match any part of a word.",
      +  "type": "boolean"
      +}
  5. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
      +  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
      +  "type": "integer"
      +}
  6. Added
  7. Removed
  8. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real behavioral context, notably that image hits carry match_reason ('image'/'attachment_text') and file_id that must then be opened, and that per_chat collapses results to one per chat with a match count. It does not discuss pagination or text-score ranking, so it stops just short of a 5.

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?

Purpose and the image-hit consequence are front-loaded, then the exact-search mode and alternatives follow in a logical order with no filler. It is dense with semicolons and runs long, but nearly every clause carries actionable information.

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 15-parameter tool with no output schema, the description conveys the two search modes, the key returned fields (match_reason, file_id, matches), and the sibling escape hatches. Remaining gaps — text relevance ranking, result ordering for non-image hits — are minor and partly covered by the parameter schema.

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 beyond it by explaining that direction/chat_kind/per_chat collectively trigger a different search mode rather than being independent filters, and by clarifying outgoing = the owner. That mode-switching semantics is not evident from the schema alone.

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 scope ('Search message content across all chats — semantic + keyword') and extends it to captionless photos/screenshots by content or OCR text. It explicitly names the sibling tools that handle adjacent cases (search.threads, search.files, search.links), so an agent can route without opening another schema.

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?

Gives concrete when-to-use guidance: quote/topic lookup, image lookup via match_reason/file_id, and an explicit mode switch — passing direction/chat_kind/per_chat turns it into an EXACT text search. It even supplies a worked example (query='Дима', direction='outgoing', chat_kind='dm', per_chat=true) and points to alternatives for threads, files, and links.

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