---
title: "Giving your own users memory"
description: "The server above is for your account. To put past.dev memory inside your product's assistant, you run an MCP server of your own over the Memory API. This is the supported shape, and it is deliberately the one that leaves your user directory with you."
canonical: https://past.dev/docs/mcp/serving-your-own-users
last-updated: 2026-08-26
---
# Giving your own users memory

> The server above is for your account. To put past.dev memory inside your product's assistant, you run an MCP server of your own over the Memory API. This is the supported shape, and it is deliberately the one that leaves your user directory with you.

Product: past.dev MCP Server. Source: https://past.dev/docs/mcp/serving-your-own-users

The question this section answers came up the moment the server above existed: can I point my users at `api.past.dev/mcp` and be done? No, and the reason is worth stating rather than burying. An MCP client signs a person in, so a shared server would have to know who all of your users are. That means past.dev holding your user directory, syncing it, and staying correct about it as people join and leave. It is your directory, the boundary belongs with you, and a memory product is the last place to be casual about whose memory is whose.

So past.dev does the half it is good at, which is the memory, and you keep the half you already own, which is identity. In practice that is a thin server: your users authenticate to **you**, exactly as they already do, and your server calls the Memory API with your own key and the audience you resolved for that person.

### The shape

1. **Your MCP server authenticates the user.** Your existing session, your existing identity provider. past.dev is not in this step.
2. **You map that user to what they are allowed to read.** A project, an audience, whatever your model is. This is the security boundary, and it stays in your code.
3. **Your tool calls the Memory API** with your server-side API key, never one held by the client.
4. **You return the result as a tool response.** `/recall` if your own model will reason over the evidence, `/answer` if you want the grounded answer, its evidence and its cost.

```bash
# Inside your MCP tool handler, after you have authenticated the user
# and resolved which project their question is allowed to reach.
curl -X POST https://api.past.dev/api/v1/answer \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -d '{ "query": "what is the Acme pilot budget?",
        "projectId": "prj_acme" }'
```

> **Keep the key on your server**
>
> A past.dev API key is organization-level. It must never reach an MCP client, a browser or a user's machine: anything holding it can read every project in your organization.
>
> During early access a project is a single visibility boundary, so per-reader scoping inside one project is not something the API enforces for you yet. If two of your users must not see each other's data, put them in separate projects and resolve which one to call in step 2.

### Why this ends up being the better trade

- **You choose the tools.** Your users get tools phrased in your product's language, not a generic memory API's.
- **You keep the audit trail.** Every call is attributable to a user you authenticated, in your own logs, with no third party to reconcile against.
- **Nothing to migrate later.** No directory sync to build now and unpick when your auth changes.
- **Most teams already run one.** If you have an MCP server for your product, this is a tool or two added to it, not a new service.

**The endpoints you will call.** The Memory API reference documents `/ingest`, `/recall` and `/answer`, with request and response shapes for each. Memory API reference: /docs/memory-api/api-reference