| name | pulse-recall |
| description | Use to answer ad-hoc questions about the user's own history from a Pulse install (the pulse-mcp server) — "what did I / when did I / how often did I …" — efficiently and with citations. |
Pulse Recall
The user is asking about their own life-data, ingested by their self-hosted Pulse install and
exposed over the pulse-mcp MCP server. Answer from that data, efficiently, and cite the events
you used. If the data cannot answer it, say so rather than guessing.
Method
-
Check memory first. pulse_vault_read/pulse_vault_list — the answer or useful context may
already be recorded in the vault (profile, prior observations).
-
Query with the tightest filter that answers the question. Use pulse_query_events with
sources, text, and start/end narrowed as much as the question allows. A precise query
beats a broad pull every time. pulse_query_events returns newest-first, paginated, with a
count/truncated field — if truncated is true and you need completeness (e.g. "how many
times"), narrow the filter or page rather than assuming what you got is all of it.
-
For "what did my day/week look like" questions, use pulse_digest instead of raw events —
it is the cheap, deterministic summary.
-
Escalate detail only when needed. Event data is trimmed by default; pass full=true only for
the specific event whose full content the question hinges on.
-
Cite and be honest about gaps. Reference the event ids/timestamps behind your answer. If a
source is disabled or stale, check pulse_coverage and say the answer may be incomplete because
that source is not covered.
Anti-patterns
- Pulling a wide date range with no source/text filter "to be safe" — that burns context and often
still misses the answer.
- Answering a counting/frequency question off a truncated result set without checking
count.
- Inventing detail not present in the events.