Skip to main content
Glama
surajtripathy07

membral

by surajtripathy07
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

list_recent_conversations

List recent chat and coding sessions by date, newest first with metadata only, to locate a conversation or coding session by when it happened before opening its full record.

Instructions

List the user's recent sessions — chats AND coding sessions (Claude Code, opencode, Copilot CLI, Codex; main sessions, not sub-agents) — from the last few days by default, newest first, metadata only. Chat rows (type "chat"): id, title, source, created_at, updated_at, message_count. Code rows (type "code"): id, project_name, git_branch, source, started_at, ended_at, turn_count, summary (up to 200 chars). Defaults to the last 7 days and both kinds. Use it to find something by when it happened (e.g. yesterday's chat → since = yesterday's date, kind = chat), then open a chat with get_conversation id= or a coding session with get_code_session id=; both return long results in parts. Results are dated records of what sessions did, not the current state of a PR or issue; check that live.

Input Schema

NameRequiredDescriptionDefault
daysNoOnly results from the last N days, a whole number 1-365 (e.g. 1 = the last 24 hours). Ignored when since is given. Default 7.
kindNoWhich rows to list: "chat", "code" (coding sessions) or "all" (default). E.g. "code" for yesterday's coding session.
limitNoMax rows to return across both kinds, a whole number 1-100 (default 30). E.g. 10.
sinceNoOnly results from this time on. ISO date "2026-09-24" (read as 00:00 UTC that day) or ISO datetime "2026-09-24T09:30:00Z" (no offset = UTC). For "yesterday" pass yesterday's date. Wins over days.
sourceNoOnly rows from this source: one of chatgpt, claude, claude-code, codex, copilot-cli, grok, opencode. Chat sources filter chats, code sources (claude-code, opencode, copilot-cli, codex) filter coding sessions. E.g. "chatgpt".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/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: defaults (last 7 days, both kinds), metadata-only return, per-type field lists including the 200-char summary cap, and that downstream get_* tools return long results in parts. It also warns results are dated records rather than live PR/issue state, which is exactly the kind of caveat annotations would otherwise supply.

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?

Front-loaded with purpose and scope, and essentially every clause carries information (row shapes, defaults, routing, caveat). It is a single dense paragraph with heavy parenthetical stacking, which costs a little readability but no sentence is filler.

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?

Five optional parameters, no annotations and no output schema — the description covers what is returned for both row types, the defaults, pagination-adjacent limit behavior implicitly, and the caveat about staleness. Nothing an agent needs to call this correctly is missing.

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 still adds value by restating the temporal defaults and by showing how natural-language intents map to parameter values (since for 'yesterday', kind for chat-vs-code). It doesn't add syntax beyond the schema's ISO examples.

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 (List) and resource (recent sessions) and immediately disambiguates scope: chats AND coding sessions, main sessions not sub-agents, newest first, metadata only. It even enumerates the row shapes per type, so an agent can distinguish it from search_conversations or session_summary without opening a 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?

Explicit when-to-use with a concrete worked example ('yesterday's chat → since = yesterday's date, kind = chat') and explicit follow-up routing to get_conversation / get_code_session. It does not name the alternative for content-based lookup (search_conversations), so the exclusion side is only implied.

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