A
licenseA
qualityA
maintenanceMCP-native, local-first memory for coding agents that turns real sessions into reusable decisions, gotchas, and domain knowledge.
17
6
MIT
ltm
The ltm server provides a centralized backend for managing Core Memory Packets — structured JSON documents capturing session context (goals, decisions, attempts, next steps) — enabling persistence, retrieval, and sharing across agent sessions and machines.
ls— List recent packets, showing ID, creation time, and goal (up to 200 results).show— Fetch a human-readable summary of a packet by ID.pull— Fetch the full raw JSON of a packet by ID.resume— Render a prompt-ready markdown resume block so an agent can continue prior work with full context.push— Upload a pre-built Core Memory Packet, with schema validation and secret/path redaction scanning before upload.save— Synthesize and save the current agent session as a Core Memory Packet (same validation aspush).rm— Delete a packet by ID (destructive, requires user confirmation).publish— Make a packet publicly accessible via an unguessable URL (requires user confirmation; idempotent).unpublish— Revoke public access to a packet without deleting it.example— Return a sample v0.2 packet locally as a shape reference before pushing.whoami— Report the configured host and token fingerprint to verify which server is targeted.platform— Return the web dashboard URL for the managed ltm platform.
Access is secured via bearer tokens, with OAuth device flow for managed instances and direct token provision for self-hosted setups. Team collaboration and packet sharing are supported through invite URLs.
ltm
Git captures what a project is. ltm captures what it ran into: the dead ends, the arguments you had with the model and lost, the constraints that shaped the current code without ever appearing in it.
That second layer is the part agents can't reconstruct from a repo. A fresh session on a different harness, a different machine, or just Monday morning starts from the diff and re-learns the rest by making the same mistakes. ltm is the smallest useful thing that stops that: a small JSON protocol (the Core Memory Packet) plus a CLI and server to move packets between sessions.
A packet is a short dossier on one obstacle. Goal, decisions you've locked in, what you've already tried, what the next step is. Five required fields. Typical size: 2 to 5 KB. Forward-compatible. The 90% of work that went smoothly never needs a packet, because the commit log already carries that.
The common path
# End of a session, agent emits a packet, redaction-checked, pushed.
ltm save
# Start of the next session, on any machine, in any harness.
ltm resume
# ✓ resume block copied to clipboard. Paste into your agent session.MCP-aware agents call save and resume as tools directly; see Wire it into your agent below.
Related MCP server: Longhand
Install
# macOS, Linux. amd64 and arm64.
curl -fsSL https://ltm-cli.dev/install | shOr from a checkout: go build -o ltm ./cmd/ltm.
See what a resume looks like
No server, no account, no auth. One command runs the whole flow against an embedded sample packet and drops a resume block on your clipboard.
ltm example --resumeThis is the same flow the demo above is showing. It's the fastest way to decide whether ltm is worth the next five minutes.
Use it
# Sign in. Three supported forms.
ltm auth # managed hub (OAuth device flow)
ltm auth https://your-server.example # self-hosted, if the server speaks RFC 8628 device flow
ltm auth https://your-server.example <token> # paste a pre-issued bearer token (what the reference ltm server wants)
# Daily driver.
ltm save # session to packet to push, in one step
ltm resume # interactive picker, copies to clipboard
ltm resume <id> # skip the picker, print to stdout
# The usual CRUD when you need it.
ltm ls
ltm show <id>
ltm pull <id>
ltm rm <id>
# Handy.
ltm example # print a valid packet, no server required
ltm update # upgrade in placeTeams
Share packets with a fixed set of people on the same server. Membership is granted through a single-use invite URL that expires in 7 days.
ltm teams create alpha
ltm invite -t alpha # prints a URL to share
ltm push packet.json -t alpha # push into the team, not personal
ltm ls -t alphaOn the invitee's machine: ltm join <url>.
Wire it into your agent (MCP)
ltm mcp speaks the Model Context Protocol over stdio. It exposes the client verbs (save, resume, ls, show, pull, push, rm, example, whoami) as tools, and it reuses whatever ltm auth already stored. No second credential surface.
# Claude Code.
claude mcp add ltm -- ltm mcp
# Cursor, Zed, Claude Desktop, Continue. Paste into the client's MCP config:
# { "ltm": { "command": "ltm", "args": ["mcp"] } }Once registered, the agent saves at the end of a session and resumes at the start of the next. You never type an ID.
Run your own server
One Go binary, SQLite on disk, bearer-token auth. HTTPS is your job: Caddy, nginx, a reverse proxy of your choosing.
ltm server init --db ~/.local/share/ltm/ltm.db # prints the root token, once
ltm server --addr :8080
ltm server issue-token laptop # name one token per machine (laptop, ci, ...)The reference server is bearer-token only. It does not implement OAuth device flow (RFC 8628) today, so clients pointed at it should use ltm auth <host> <token>. The managed hub implements device flow through Doorkeeper; a second implementation of the ltm protocol is free to do the same, and ltm auth <host> will then work against it.
Packets travel. Secrets don't.
The core promise is that packets move between machines, teams, and agents, which means what travels with them has to be something you actually meant to send. Every packet is scanned before it leaves your machine. Any hit blocks the push unless you opt in with --allow-unredacted.
The pre-flight refuses absolute paths (POSIX and Windows), AWS access keys and ARNs, GitHub tokens, JWTs, private-key headers, Google API keys, Slack tokens, Stripe keys and webhook secrets, and SSH public keys. It inspects only the spec's travelable text fields (goal, next_step, constraints, decisions.*, methods.*, attempts.*, open_questions). Structure carries no content; content is where the leaks are.
This is load-bearing, not cosmetic. The person writing the packet is not always the person reading it. Full pattern list and rationale in SPEC.md.
Principles
Intent is portable; configuration isn't. Packets never carry your CLAUDE.md, skills, prompts, or tool setup.
Self-host or nothing. If it doesn't run on a $5 VPS, it's not done.
Model-agnostic. A packet written by Claude is readable by GPT, Gemini, or whatever comes next.
Spec first, code second. The protocol is the product; the CLI and server are reference implementations.
Redact aggressively. Secrets and local state never ride along.
What's not here yet
Direct share-by-username between users (targeted peer-to-peer hand-off, distinct from the public-link sharing ltm publish already provides), federation. Windows binaries (Linux and macOS only, amd64 and arm64). A portable conformance suite for second implementations; the Go reference tests stand in for one today. A fuzz and end-to-end harness on top of the existing unit and integration tests. Chaining is defined in the v0.2 schema (parent_id) but the server doesn't surface it yet.
How this is built
ltm is written with LLM assistance, and says so out loud. A human drives the design, writes the prose, reviews every line, and is accountable for what lands; a coding agent helps with implementation. Commits touched by an agent carry an Assisted-by: trailer naming the tool — the same convention as the Linux kernel's AI Coding Assistants policy. Disclosure, not disguise.
If you send a PR that an LLM helped write, do the same: add an Assisted-by: trailer, read the diff as if you'd written it yourself, and own it. Details in CONTRIBUTING.md.
Further reading
SPEC.md for the wire format and packet schema. RESEARCH.md for the literature review that shaped v0.2 (agent memory, prompt compression, case-based reasoning, ADRs). CONTRIBUTING.md for how to propose changes and how to port a second implementation. SECURITY.md for reporting issues.
Status
Pre-alpha. The spec is a draft; breaking changes are on the table before v1.0. Pin against ltm_version when you write a packet.
License
Available Tools
12 toolsexampleA
Return an embedded sample v0.2 Core Memory Packet. Useful as a shape reference before calling 'push'. No server round-trip.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds the key behavioral trait 'No server round-trip', informing the agent that this is an embedded operation with no network cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: two sentences, front-loaded with purpose and usage. Every sentence adds value with zero waste.
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 zero-parameter, no-output-schema tool, the description covers purpose, usage context, and a key behavioral trait, making it complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the baseline is 4. The description adds no parameter-specific info, but none is needed.
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 description clearly states it returns a sample Core Memory Packet and distinguishes itself from sibling tools by referencing 'push' specifically as the intended context.
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?
Explicitly indicates when to use it ('before calling push'), but does not provide explicit when-not-to-use or alternatives beyond naming push.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lsB
List recent packets on the configured ltm server. Returns a table with ID, creation time, and goal.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of packets to return (default 50). |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only states the action and output, omitting important details like whether the operation is read-only, any prerequisites, permission requirements, or how 'recent' is defined. This lack of behavioral context weakens transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, free of extraneous information. Every sentence serves a clear purpose: stating the action and the output structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the basic purpose and output. However, it lacks usage context and behavioral details that would make it fully self-contained. The output schema absence is partially mitigated by describing the returned fields.
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% (one parameter 'limit' with description). The tool description adds no additional parameter semantics beyond the schema. Baseline score of 3 is appropriate as the schema already documents the parameter adequately.
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 description clearly states the verb 'list', the resource 'recent packets', the server 'ltm', and the output format 'table with ID, creation time, and goal'. It effectively distinguishes from sibling tools like 'push' or 'pull' which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. No when-to-use or when-not-to-use context is provided, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
platformA
Return the URL of the managed ltm platform's web dashboard so the agent can surface it to the user. Errors when the user is configured against a self-hosted server. No server round-trip.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Absent annotations, the description discloses two behavioral traits: 'No server round-trip' and an error condition for self-hosted servers. It does not detail authentication needs, return format, or side effects. This adds some value beyond the empty schema but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences each serve a distinct purpose: stating the action, noting an error condition, and clarifying no network call. There is no fluff, and every sentence earns its place.
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?
For a parameterless tool with no output schema, the description adequately covers the return value (URL), an error condition, and a performance characteristic (no round-trip). It is nearly complete but could briefly mention that the URL should be presented as a clickable link.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage (trivial), the description has no need to add parameter meaning. The baseline for no-parameter tools is 4, and the description appropriately does not introduce irrelevant parameter details.
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 description clearly states the tool returns the URL of the managed LTM platform's web dashboard for surfacing to the user. It identifies the specific verb 'return' and resource 'URL', making the purpose unambiguous. It effectively distinguishes from sibling tools like push or publish, which are mutation-focused.
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?
The description mentions an error condition ('Errors when the user is configured against a self-hosted server') but does not explicitly instruct when to use this tool versus alternatives. Usage is implied by the purpose, but no when-not-to or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publishA
Publish a packet to a public URL anyone can view (no account required) and copy as a prompt. The URL is unguessable (it embeds the packet's ULID). Returns the public URL. Idempotent — re-publishing a published packet preserves the original URL and timestamp. Confirm with the user before calling: this makes the packet content world-readable.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Packet ID to publish. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: public URL, no account required, unguessable URL, idempotent, world-readable. No annotations provided, so description carries full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding essential info: action, URL property, idempotence and user confirmation. No extraneous words.
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?
Explains return value (public URL), side effects (world-readable), idempotence, and user confirmation. Complete for a single-parameter tool with no output schema.
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 covers parameter 'id' with 100% description coverage. Description adds no extra detail about the parameter beyond what schema provides, so baseline 3 is appropriate.
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 description clearly states it publishes a packet to a public URL, specifying the resource (packet) and action (publish). It distinguishes from siblings like 'unpublish' and 'save'.
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?
Includes explicit warning to confirm with user before calling, and notes idempotency. Could mention when not to use (e.g., already published) but provides adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pullA
Fetch a packet by ID and return the raw JSON document. Use when you need the full v0.2 packet — otherwise prefer 'show' or 'resume'.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Packet ID. |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states return type ('raw JSON document') and version ('full v0.2 packet'), but does not explicitly mention read-only nature or potential side effects. However, the verb 'Fetch' implies read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each with clear purpose: first defines action and return, second gives usage guidance. No redundant words.
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?
Given simple schema (one parameter, no output schema, no annotations), description covers what the tool does, when to use it, and what it returns. Minor gap: no mention of error cases, but adequate for the complexity level.
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 has one parameter 'id' with description 'Packet ID,' and coverage is 100%. Description adds no additional parameter details beyond the schema, so baseline score of 3 applies.
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?
Description states 'Fetch a packet by ID and return the raw JSON document,' providing a specific verb and resource. It also distinguishes from siblings by mentioning 'full v0.2 packet' and naming 'show' and 'resume' as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you need the full v0.2 packet — otherwise prefer 'show' or 'resume'.' This gives clear context for when to use and directs to alternatives, meeting the highest standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pushA
Send a Core Memory Packet to the configured ltm server. The packet is schema-validated and scanned for secrets/absolute paths before upload. Pass the packet as a JSON object under 'packet'. Use 'ltm example' via the 'example' tool if you need a valid shape reference.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| allow_unredacted | No | Skip the redaction pre-flight. Only set true when the caller has already reviewed the content. | |
| packet | Yes | The full Core Memory Packet JSON (v0.1 or v0.2). |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the packet is schema-validated and scanned for secrets/absolute paths. However, it omits details about success responses, error handling, or whether the operation is side-effect-free.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and well-structured: the first sentence states the primary purpose, and the second gives usage tips and an alternative. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sparse annotations, the description is reasonably complete for basic usage. It covers validation and scanning but lacks details on return values, error conditions, and the implications of sending packets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that 'allow_unredacted' skips the redaction pre-flight, which is not fully clear from the schema alone. This enriches understanding beyond the parameter descriptions.
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 clearly states the action (send a Core Memory Packet to the configured ltm server) and the resource (Core Memory Packet). It also mentions validation and scanning. However, it does not explicitly distinguish this tool from its siblings, such as 'publish' or 'save', which might have overlapping functionality.
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?
The description provides guidance on when to use the tool (sending packets) and references the 'example' tool as an alternative for obtaining a valid shape reference. It does not, however, state when not to use this tool or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resumeB
Render a prompt-ready resume block for a packet so the current agent can continue prior work. Output is markdown intended to be treated as authoritative context.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Packet ID. |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It indicates output is markdown and authoritative, but does not disclose whether the tool is read-only, has side effects, or requires specific permissions.
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?
The description is only two sentences and front-loads the main action and purpose. Every sentence adds value, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic purpose and output format. However, it lacks contextual details like whether the resume block is read from or written to, or any preconditions.
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% with a clear description for the single parameter. The tool description adds no further parameter detail beyond the schema, so baseline 3 is 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?
The description clearly states the action ('Render a prompt-ready resume block') and target ('for a packet'), and explains the output's purpose ('authoritative context to continue prior work'). It is specific but does not distinguish from sibling tools.
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?
The description implies usage when resuming prior work, but provides no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rmA
Delete a packet by ID from the server. Destructive — confirm with the user before calling.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Packet ID to delete. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is destructive and performs deletion, which is sufficient for this simple operation. Additional behavioral details like reversibility or auth are not covered but are implied by 'destructive'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences. The first states the purpose, the second adds a critical warning. No wasted words.
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 simple tool with one required parameter and no output schema, the description covers the essential: what it does (delete a packet) and the destructive nature. No output schema means no need to explain return values. Complete enough for effective use.
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?
The input schema has 100% coverage with a parameter description 'Packet ID to delete.' The description mirrors this with 'by ID,' adding no extra meaning. Baseline is 3 given high schema coverage.
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 description clearly states 'Delete a packet by ID from the server.' It specifies the verb (delete) and the resource (packet by ID), distinguishing it from sibling tools like 'ls' (list) or 'publish'.
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?
The description includes 'Destructive — confirm with the user before calling,' providing explicit guidance on when to use (only after user confirmation) and the destructive nature. It does not explicitly mention alternatives but is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saveA
Save the current session as a Core Memory Packet. Build the packet JSON from the active conversation — goal, locked decisions, failed attempts, open questions, next step — and pass it as 'packet'. Same validation and redaction as 'push'; use this when the intent is 'persist my session' rather than 'ship a pre-built packet'.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| allow_unredacted | No | Skip the redaction pre-flight. Only set true when the caller has already reviewed the content. | |
| packet | Yes | The full Core Memory Packet JSON synthesized from the current session. |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It mentions 'same validation and redaction as push' but does not detail what that entails or describe side effects like data mutation. Adds some context but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose, second provides construction guidance and usage comparison. Efficiently structured.
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?
With 2 parameters, nested object, and no output schema, the description clarifies packet content expectations and references sibling 'push'. It could mention the tool's role in the session management suite but is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds meaning: it explains that 'packet' should be built from the active conversation with specific fields, and clarifies the role of 'allow_unredacted' in skipping redaction pre-flight.
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 description clearly states the tool saves a session as a Core Memory Packet. It distinguishes from the sibling 'push' by specifying the intent: 'persist my session' vs 'ship a pre-built packet'. This provides a clear verb+resource and differentiation.
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?
The description explicitly says when to use this tool: 'when the intent is persist my session'. It contrasts with 'push' and mentions building the packet from the active conversation. It does not list exclusions but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
showA
Fetch a packet by ID and return a human-readable summary (goal, constraints, decisions, attempts, next step).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Packet ID. |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It indicates a read operation (fetch) and returns text, but does not disclose potential side effects or required permissions. The description is adequate but not enriched beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the tool's purpose and output. Every part is necessary, and there is no redundant or extraneous 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?
Given the simple tool (one parameter, no output schema), the description covers what the tool does and what it returns. It does not mention error handling or format of the summary, but for a straightforward fetch operation it is largely complete.
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% for the single parameter 'id', which already states 'Packet ID.' The description adds context by linking the parameter to the tool's purpose ('by ID'), but does not provide additional detail beyond what the schema offers.
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 description clearly states the action (fetch a packet by ID) and the output (human-readable summary with specific elements like goal, constraints, decisions, attempts, next step). This distinguishes it from sibling tools like 'ls' which likely list packets, so purpose is specific and clear.
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?
The description implies use when you need detailed information on a specific packet, but it does not provide explicit guidance on when not to use it or compare to alternatives like 'ls' or 'publish'. Usage is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unpublishA
Revoke public access to a previously published packet. The packet itself is not deleted — only the public URL stops working.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Packet ID to unpublish. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It transparently states that the packet is not deleted, only the public URL stops working, which is a key behavioral trait not captured by annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the action, and every word earns its place.
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?
Given the simple tool with one parameter, no output schema, and no annotations, the description covers the essential purpose and behavioral nuance, leaving little ambiguity.
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?
With 100% schema description coverage, the baseline is 3. The description adds no extra meaning beyond the schema's parameter description.
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 description clearly specifies the action 'revoke public access' and the resource 'previously published packet', distinguishing it from sibling tools like 'publish' and 'rm'.
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?
The description does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare with alternatives like 'rm' or 'publish', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiA
Report the configured ltm host and a short fingerprint of the stored token. Use to verify the server the MCP will hit before pushing.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes a read-only report operation, but with no annotations, it could more explicitly state that no modifications occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words, effectively front-loading the purpose and usage.
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?
Sufficient for a simple tool with no parameters and no output schema, though a brief note on fingerprint format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; the description adds value by explaining what the tool returns (host and fingerprint) beyond the empty schema.
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?
Clearly states it reports the configured ltm host and a short token fingerprint, distinguishing it from action-oriented siblings like push or publish.
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?
Explicitly advises using it to verify the server before pushing, providing clear context for its use, though no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
12 tool updates
v0.11.0- First observed
example - First observed
ls - First observed
platform - First observed
publish - First observed
pull - First observed
push - First observed
resume - First observed
rm - First observed
save - First observed
show - First observed
unpublish - First observed
whoami
TDQS
A3.9/5.0
Disambiguation5/5
Each tool has a clear, distinct purpose. For example, 'push' sends pre-built packets while 'save' persists session state, and 'show' returns a summary vs 'pull' returns raw JSON. No overlap causes confusion.
Naming Consistency4/5
All tool names are lowercase single words, but they mix short names (ls, rm) with full words (publish, resume) and a few noun forms (example, platform). While the style is uniform, the part-of-speech varies slightly.
Tool Count5/5
With 12 tools, the server covers core packet management (CRUD, listing, publishing, session saving) without being bloated. Each tool earns its place for a focused domain.
Completeness3/5
The tool set lacks an update operation for packet content (only delete+re-push). Additionally, there is no filtering or search capability beyond listing all packets. These are notable gaps for a complete lifecycle.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Portable memory for AI agents: capture once, recall across Claude, Cursor, and any MCP client.
- mcpOAuthai.butlerbrain
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Persistent memory for AI agents — log and recall conversation context over MCP.
Persistent memory for AI agents with OAuth-backed hosted MCP access.
Related MCP Servers
- AlicenseAqualityAmaintenancePersistent local memory for Claude Code that indexes every session's JSONL file verbatim into SQLite + ChromaDB. Exposes 17 MCP tools for semantic recall, deterministic file replay, and fuzzy "do you remember when..." queries across your entire session history — no API calls, nothing leaves the machine.1713MIT
- AlicenseAqualityDmaintenanceGoverned memory for coding agents with trust lifecycle, conflict detection, staleness tracking, and health scoring. SQLite + FTS5, zero infrastructure. Works with Claude Code, Cursor, Codex, Windsurf.133MIT
- AlicenseBqualityBmaintenancePersistent memory and session intelligence for AI coding assistants. Auto-tracks mistakes, decisions, and context via hooks. Mines your full session history for patterns, predictions, and cross-session search.2116MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dennisdevulder/ltm'
If you have feedback or need assistance with the MCP directory API, please join our Discord server