Skip to main content
Glama

memory_search

Search stored journal events and archived Markdown notes by text, tag, or date range to retrieve past context from local memory files.

Instructions

在记忆里检索。默认同时搜 JOURNAL 事件和归档文件(FACT.archive.md)——归档是从 FACT 搬走的旧段落,不占固定注入,靠这里找回。query 为空时只按 tag / 日期过滤 JOURNAL(= 列出某段时间的事)。tag 可写多个(逗号分隔),命中任一即可;after / before 用 YYYY-MM-DD(本地日期,含当天)。返回最近 limit 条事件(带时间戳与 tags)和命中的归档行。大小写不敏感的普通子串匹配,不是语义检索。

Input Schema

NameRequiredDescriptionDefault
tagNo
afterNo
limitNo
queryNo
beforeNo
include_archiveNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.1
    • addedInput schema / properties / after
      Added value: +{
      +  "default": "",
      +  "title": "After",
      +  "type": "string"
      +}
    • addedInput schema / properties / before
      Added value: +{
      +  "default": "",
      +  "title": "Before",
      +  "type": "string"
      +}
    • addedInput schema / properties / include_archive
      Added value: +{
      +  "default": true,
      +  "title": "Include Archive",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / query / default
      Added value: +""
    • addedInput schema / properties / tag
      Added value: +{
      +  "default": "",
      +  "title": "Tag",
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "query"
      -]
  2. First observedv0.1.0

TDQS

A4.5/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 it well: default dual-source search, the nature of archive segments (moved old FACT paragraphs, not fixed-injected), empty-query behavior, case-insensitive substring matching rather than semantic search, and what is returned (recent limit events with timestamps and tags plus matching archive lines).

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 the core action, then layers defaults, filtering semantics, and matching behavior in a tight sequence. Dense but nearly every clause carries distinct information; only the archive parenthetical is slightly explanatory rather than operational.

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 6-parameter, zero-schema-coverage, no-annotation tool, the description supplies the missing parameter semantics and matching behavior, and it need not detail return shapes since an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does: tag accepts comma-separated multiples with OR semantics, after/before use YYYY-MM-DD local dates inclusive of the boundary day, limit caps returned events, and include_archive is implied by the default dual-source behavior.

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 clear verb and resource, and the description immediately explains the two search scopes (JOURNAL events and FACT.archive.md). It distinguishes searching from the reading/writing siblings by describing what archive retrieval actually means, though it never names memory_read or memory_stats explicitly.

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?

It tells the agent that an empty query becomes a pure tag/date listing of JOURNAL, and that archive is included by default but can be excluded. That covers the main use cases, but there is no explicit 'use this instead of X' routing against the sibling tools.

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