Skip to main content
Glama

pulse

Warm up an agent session with the current checkpoint, open handoffs, anti-patterns, and recent notes, scoped to a domain, to resume work in context.

Instructions

Session warm-up: latest checkpoint + open handoffs/anti-patterns + recent notes.

Picks the checkpoint by created_at DESC, never by similarity -- a similarity-ranked top-1 can return a stale checkpoint over a same-day one, which is exactly the failure mode this avoids. latest_checkpoint is returned in full (that's the point of pulse), with its relations attached so linked memories are visible without a separate get_relations call. handoffs and anti_patterns are notes left for whoever resumes; recent_notes are the newest note()'d facts, as recency breadcrumbs -- for relevance-ranked recall use recall()/search(). Those three lists are snippet-truncated -- call get_memory(uid) for one in full.

latest_checkpoint and those three lists carry est_tokens, the estimated cost of a record's FULL content: on a truncated one that is what the get_memory(uid) would cost, on latest_checkpoint it is what this response already spent. diagrams has no bodies to price.

diagrams lists the documented flows by title only, never inlined: a whole graph would swamp a warm-up. Read one with get_diagram(uid) when the work actually touches that routine.

domain warms up a path and everything under it, so pulse('acme/x100') is the module-wide brief and pulse('acme/x100/p200') the routine's. A domain that names only the deep end of a path ('p200') is resolved to the branches it sits in -- scope.paths reports which, and an ambiguous name resolves to ALL of them.

scope is the rest of the brief: what the scope HOLDS, next to what came back. This is a warm-up, so each list stops at a handful and the newest few of a busy child can fill it on their own -- scope.not_shown counts what that left behind, per type, and scope.subdomains says which level it is sitting in (own = filed there, subtree = with its descendants). Read them as the drill-down plan: search(query, domain=...) or list_by_domain(domain, type=..., limit=...) on the child that holds what this pass only counted. A pulse is the state of a scope, never its contents.

scope.stale is the one thing here about DECAY rather than contents: how many memories in the scope carry a review_after date that has passed. Present only when non-zero. It means somebody who knew the subject said when to look again and nobody has -- optimize_scan lists which ones, with their source_ref.

A scope holds what is CROSS-LISTED into it as well as what is filed there, so warming up an end-to-end flow brings back the routines that are steps of it wherever they live. scope.also counts how much of the brief arrived that way, and a subdomain carries its own also -- present only when non-zero, so a store that never cross-lists never sees the field.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/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 behavioral burden and does so unusually well: it discloses that the checkpoint is selected by created_at DESC rather than similarity (and why), that latest_checkpoint is returned in full with relations attached, how est_tokens is priced differently for truncated vs full records, and that the three lists are snippet-truncated requiring get_memory(uid).

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?

It is long (several hundred words) for a one-optional-param tool, but it is front-loaded with the payload summary and virtually every paragraph introduces distinct, non-derivable behavior (est_tokens pricing, scope.stale, scope.also). Prose density is the only weakness; 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?

There is no output schema and no annotations, so the description must define the response shape, which it does field-by-field — latest_checkpoint, handoffs, anti_patterns, recent_notes, diagrams, and the full scope sub-structure (paths, not_shown, subdomains, stale, also). An agent can interpret the result without guessing.

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 description coverage is 0% for the single `domain` param, so the description must compensate, and it does in depth: pulse('acme/x100') vs pulse('acme/x100/p200'), resolution of a deep-end-only name to all branches, scope.paths reporting the resolution, ambiguity resolving to ALL matches.

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?

The opening line names a specific verb-resource and scope: 'Session warm-up: latest checkpoint + open handoffs/anti-patterns + recent notes,' then enumerates every component of the payload (checkpoint, three lists, diagrams, scope). It explicitly distinguishes itself from siblings recall()/search() as the recency-based alternative.

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 routes the agent elsewhere in several places ('for relevance-ranked recall use recall()/search()', 'Read one with get_diagram(uid)', 'optimize_scan lists which ones', 'search(query, domain=...) or list_by_domain(...)'). It lacks an explicit forward statement of when to call pulse itself, but the surrounding guidance is rich and actionable.

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