Skip to main content
Glama
hatrieukim

lifelog

by hatrieukim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

summary

Creates a day or week overview of your activities from Claude Code sessions, meetings, calendar, app usage, and reading. Use it to review your time or find episode IDs for deeper searches.

Instructions

What the user did on one day or in one week, written from all sources: Claude Code sessions by project, recorded conversations and online meetings, the calendar, time spent in apps on the Mac, and pages read.

A day starts with an overview paragraph, then one section per source. A week has a summary by theme (main
work, results, people met, open items) and the overview of each day. Today and the current week are written
from the data so far. Every conversation and session carries its episode id, to look it up with `search`.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoA day as 2026-10-13. Defaults to yesterday. With period "week", any day of the week (Monday to Sunday).
detailNoDay only. False lists each Claude Code session by time, title and episode; true adds the full summary of every session, which can be long.
periodNo"day" or "week".day

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 disclose the output shape (overview paragraph then one section per source; a week adds a theme summary plus each day's overview) and the partial-data caveat for today/current week. It does not state read-only nature, cost/length, or pagination limits, but the return-content disclosure is substantive.

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?

Three short paragraphs, front-loaded with the purpose, then output structure, then the cross-reference. The sources enumeration is slightly list-heavy but each clause maps to a real data source. No filler or repetition.

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 return values need not be re-explained, and the description sensibly focuses on structure and sources instead. For a zero-required-parameter read tool, the agent has enough to call it correctly; only the sibling-routing relationship to `timeline`/`people` is left implicit.

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 coverage is 100%, so the schema already documents `date`, `detail`, and `period` incl. defaults and the enum. The description adds no syntax, format, or interaction detail beyond what the schema provides (its mention of period structure maps to the schema's own description), so baseline 3 applies.

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?

The description names a specific verb+resource: it generates a written summary of the user's activity for one day or one week, from enumerated sources. An agent can tell it produces a synthesized report. It only partially differentiates from siblings: it references `search` for episode lookup, but never clarifies how it relates to `timeline` or `people`.

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?

Usage is implied rather than stated: the agent infers that `search` is the follow-up for episode ids, and that today/current week produce partial data. There is no explicit when-to-use versus `timeline` (raw events) or `people`, nor any stated prerequisites or exclusion conditions.

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