---
title: "What the assistant can do"
description: "Two tools over your own past.dev memories. Each one is scoped, and each one runs as you."
canonical: https://past.dev/docs/mcp/tool-reference
last-updated: 2026-08-26
---
# What the assistant can do

> Two tools over your own past.dev memories. Each one is scoped, and each one runs as you.

Product: past.dev MCP Server. Source: https://past.dev/docs/mcp/tool-reference

Read tools are marked `read`, tools that change something are marked `write`. Nothing here deletes data: the writes add to what past.dev knows, they never remove from it.

The surface is deliberately small. This server exists so you can inspect and poke your own account from an assistant while you build; the Memory API is where an application reads and writes at volume. Anything you can do here you can also do with `POST /api/v1/recall` and `POST /api/v1/answer`, against any project, without a browser sign-in.

| Tool | Kind | What it does |
| --- | --- | --- |
| `list_my_memories` | read | List the durable facts past.dev has learned about you: preferences, working style, context. Yours only. Requires the `memories:read` scope. |
| `add_memory` | write | Save a new one, optionally with a category and an expiry in days. It lands in the same store past.dev itself reads, so it shapes past.dev's answers elsewhere too. Requires the `memories:write` scope. |

> **Looking for search, ingestion or document tools?**
>
> They are not here, on purpose. Bulk ingestion, ranked retrieval and grounded answers are the Memory API's job, and they are what your application should call: `POST /api/v1/ingest`, `POST /api/v1/recall`, `POST /api/v1/answer`.
>
> If you want those reachable from an assistant, whether yours or your users', wrap them in your own MCP server. Section 04 shows the shape.