Skip to main content
Glama
Sign In
express-reader-mcp

express-reader-mcp

by Eflarus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

express_search_messages

Search a chat's full message history by query, resolving by name or exact chat ID and optionally filtering to recent days; opening the chat marks it read.

Instructions

Native server-side search within a chat — finds matches across the WHOLE history (not just loaded messages), fast. Resolve the chat by name or exact chatId; if name matches several, the matches are returned instead of searching. Returns matching messages (syncId/time/from/text + attachment metadata). Optionally filter with sinceDays. truncated: true means the app capped results (~100). WARNING: opens the chat (MARKS IT READ).

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": "express_search_messages"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoPerson/chat name to resolve
limitNoMax results returned (default 100)
queryYesSearch text
chatIdNoExact chat id (overrides name)
sinceDaysNoOnly matches within the last N days (default: all history)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations supplied, the description carries the whole burden and does so: it discloses the search scope (full server-side history), the return payload fields, the `truncated: true` cap signal (~100), and critically the side effect that searching OPENS THE CHAT AND MARKS IT READ. That side-effect warning is the single most important thing an agent could not infer from structured fields.

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?

Dense and front-loaded — scope first, then chat resolution, then return shape, then the read-marking warning last as the highest-stakes caveat. Telegraphic phrasing and backticked identifiers keep it short with no sentence that fails to add 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 5-parameter search tool with no output schema, the description compensates by enumerating returned fields and the truncation flag. The one gap is the failure path when `name` resolves to nothing at all, which is left unstated.

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, but the description adds real meaning: it explains the `name`/`chatId` precedence interaction and the ambiguity fallback, ties `limit` to the ~100 cap behind `truncated`, and frames `sinceDays` as an optional history-narrowing filter versus the default of all history.

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?

"Native server-side search within a chat" names a specific verb and resource, and "matches across the WHOLE history (not just loaded messages)" immediately distinguishes it from the sibling express_read_chat, which only sees loaded messages. An agent can pick correctly without opening either 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?

The chat-resolution rule is spelled out (resolve by `name` or exact `chatId`, and if `name` is ambiguous the matches come back instead of a search), which is exactly the branching an agent needs. It stops short of explicitly stating when to prefer this over express_read_chat for a small chat, so it is clear context rather than full when/when-not guidance.

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

Deploy Server

Other Tools