Skip to main content
Glama
hatrieukim

lifelog

by hatrieukim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search

Look up recorded conversations and Claude Code sessions by meaning. Get verbatim passages and extracted facts with timestamps, speakers, and source references.

Instructions

Tìm trong bộ nhớ của người dùng: hội thoại đã ghi âm và các phiên làm việc với Claude Code. Trả về hai phần.

Nguyên văn: các đoạn gần nghĩa nhất với câu hỏi, có giờ, người nói, nguồn (ghi âm hay dự án nào), và độ gần
từ 0 tới 1. Độ gần dưới khoảng 0,5 thường là không liên quan. Với phiên Claude Code, đoạn ghi "tóm tắt cả phiên"
là bản tóm tắt do máy viết; các đoạn khác là lời thật của người dùng và của Claude trong phiên đó.
Hỏi việc đã làm ở một dự án thì nêu tên dự án trong `query` và dùng `since`, `until` để khoanh ngày.

Fact: những điều đã được chắt lọc từ hội thoại (ai, việc gì, ở đâu, quan hệ), kèm thời gian fact đó đúng.
Fact ghi "ĐÃ HẾT ĐÚNG" là điều từng đúng nhưng về sau đã đổi. Hội thoại không nhắc tên riêng nào thì
thường không có fact, chỉ có nguyên văn.

Mỗi kết quả ghi mã episode và số lượt nói để dẫn nguồn. Không thấy kết quả phù hợp thì nói là không
tìm thấy, đừng đoán.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoSố kết quả tối đa cho mỗi phần.
queryYesĐiều cần tìm, viết bằng tiếng Việt như một câu nói bình thường. Tìm theo nghĩa, không cần trùng chữ. Đừng nhét ngày tháng hay tên người nói vào đây, dùng các tham số bên dưới.
sinceNoChỉ lấy những gì được nói từ mốc này. Dạng 2026-10-13 hoặc 2026-10-13T09:30, giờ Việt Nam.
untilNoChỉ lấy những gì được nói trước mốc này. Ghi một ngày trơn như 2026-10-13 thì tính hết ngày đó.
speakersNoOnly passages where these people speak, by name (e.g. "Kim"). Voices are recognised across recordings once the user has named them. Unnamed voices carry a role label (e.g. "nhân viên tổng đài") or SPEAKER_01, which only mean something inside one episode.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/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 well: it explains the two output sections, that similarity under ~0.5 is usually irrelevant, that the 'tóm tắt cả phiên' passage is machine-written while others are verbatim speech, and that facts marked 'ĐÃ HẾT ĐÚNG' were once true but are no longer. It omits operational details like latency, auth, or scope limits.

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 is front-loaded in the first sentence, followed by clearly separated sections for the two result types. It is somewhat long and repeats the 'dates belong in since/until, not query' advice already in the schema, but nearly every sentence carries 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?

An output schema exists, so raw return shape need not be restated, yet the description usefully covers interpretation of returned fields (similarity scale, fact staleness, episode/turn identifiers) and the no-match fallback. Nothing essential to calling the tool correctly appears missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents every parameter including query phrasing, date formats, and the unnamed-voice caveat. The description's date/project guidance is consistent with but not additive to the schema, making the baseline 3 appropriate.

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 (tìm/search) and a specific resource (bộ nhớ người dùng: hội thoại đã ghi âm và các phiên Claude Code), and describes the two-part return. It does not explicitly contrast itself with siblings (summary, people, timeline), so an agent must infer the boundary from the corpus description alone.

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 practical in-tool guidance (put project name in `query` and bound dates with `since`/`until`; say nothing was found rather than guessing), which is genuine usage context. However it never names an alternative tool or states when another sibling should be preferred, so the routing decision 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