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

express-reader-mcp

by Eflarus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

express_read_chat

Retrieve decrypted chat messages from a specified number of past days by name or exact chat ID, paging back through history. Opening the chat marks it read and may send a read receipt.

Instructions

Open a chat and return its decrypted messages over the last sinceDays days. Pages back through the app's history scroll to cover ranges beyond the initial ~1 week. Resolve the person by name OR pass an exact chatId; if name matches several chats, the matches are returned instead of reading. WARNING: opening a chat MARKS IT READ and may send the sender a read receipt. coversWholeRange: false means the range wasn't fully reached within maxScrolls; historyExhausted means there are no older messages.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "express_read_chat"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoPerson/chat name to resolve (direct chats)
limitNoMax messages returned (default 200)
chatIdNoExact chat id (overrides name)
sinceDaysNoHow many days back (default 7)
maxScrollsNoMax history pages to scroll back (default 40, ~50 msgs each)
fromOpponentOnlyNoOnly the other person's messages, excluding your own (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it warns that opening a chat MARKS IT READ and may send a read receipt, and it explains paging via history scroll and the meaning of `coversWholeRange: false` and `historyExhausted`. These are exactly the side-effect and completeness disclosures an agent cannot get 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?

Four dense sentences, front-loaded with purpose before resolution mechanics, then the warning, then the return-flag semantics. No filler and no restatement of the schema property descriptions.

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 6-parameter read tool with no annotations and no output schema, it covers side effects, pagination limits, and ambiguity handling well. Remaining gaps are minor: nothing about the shape of returned message objects or what happens when a name matches no chat at all.

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 baseline is 3, but the description adds real meaning: it explains that scrolling is needed to reach ranges 'beyond the initial ~1 week' (contextualizing the sinceDays default) and ties `maxScrolls` to the `coversWholeRange` outcome. `limit` and `fromOpponentOnly` are left to the schema, which keeps it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource plus scope: 'Open a chat and return its decrypted messages over the last `sinceDays` days.' An agent knows exactly what it gets. It does not, however, distinguish itself from siblings like express_read_thread or express_search_messages, so the agent must infer which reader applies to which target.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives operational guidance for resolving the target (name OR exact chatId, with name collisions returning matches instead of reading) but never states when to prefer express_read_thread or express_search_messages. Usage is implied by the resource name rather than declared against alternatives.

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