Agentage Memory 0 an open, files-first memory server for any MCP client (remote, OAuth 2.1 + DCR)

[vreshch]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

Hi all 👋 Sharing a remote MCP server I've been building: agentage Memory.

The gap I kept hitting: every assistant now has its own memory (ChatGPT memory, Claude memory, …), but it's siloed per-vendor, you can't see the raw data, and you can't move it between tools. I wanted one memory that any AI can read and write - and that I actually own.

What it is: a hosted, remote MCP server that exposes a single personal memory as plain Markdown files. Anything that speaks MCP can read/write it, and the same notes are mirrored locally as .md you can open in your editor or export anytime.

Server details

• Transport: Streamable HTTP
• Endpoint: https://memory.agentage.io/mcp
• Auth: OAuth 2.1 + PKCE + Dynamic Client Registration — no manual client setup; the client registers itself and you sign in once
• Tools (6):
  • memory__search - full-text search across your memory
  • memory__list - folder-tree outline of what's stored
  • memory__read - read a note (raw Markdown)
  • memory__write - create / overwrite a note
  • memory__edit - in-place edits (replace / append)
  • memory__delete - remove a note

Connect (any remote-MCP client, e.g. Claude Code):

{
  "mcpServers": {
    "agentage-memory": {
      "type": "http",
      "url": "https://memory.agentage.io/mcp"
    }
  }
}

The first call kicks off the OAuth flow via DCR; after sign-in the tools show up.

What's a bit different from other memory servers

• Files-first — the source of truth is plain Markdown you own, not an opaque vector DB. Export anytime.
• Cross-vendor — one memory shared across whatever MCP clients you use, instead of N vendor silos.
• Remote + real auth — full OAuth 2.1 + PKCE + DCR rather than a local stdio stub or an API key pasted into a config file.

Links

• Site: https://agentage.io/
• MCP endpoint: https://memory.agentage.io/mcp
• Documenation: https://agentage.io/blog/mcp-endpoint-is-live

Would love feedback from this community — especially on the OAuth/DCR flow and the tool surface (naming, the search/list split, anything you'd expect from a memory server that's missing). Happy to dig into any of the design choices. 🙏

Relevant Links

• Site: https://agentage.io/
• MCP endpoint: https://memory.agentage.io/mcp
• Documenation: https://agentage.io/blog/mcp-endpoint-is-live

[cristianleoo]

The files-first shape is the part I like most here. For shared agent memory, being able to inspect and export the raw Markdown is a much better operator story than an opaque vector store.

On the tool surface, I would keep search, list, and read separate from write, edit, and delete in both naming and authorization. Memory looks harmless, but write-capable memory is effectively future prompt/context control. A poisoned or mistaken note can change later agent behavior long after the original session is gone.

For OAuth/DCR, the things I would want visible to the user or admin are:

• which MCP client registered
• which scopes it received: read, write, edit, delete
• whether the grant is per-user, per-workspace, or per-device
• last access and last write/delete time
• an easy revoke path per client
• an audit record for destructive or bulk edits

For the tools themselves, I would consider making writes more explicit than a generic overwrite path. For example, append and patch-style edits are usually easier to review than full-note replacement. If full overwrite stays, I would want an old revision id or content hash in the request so a stale agent cannot accidentally clobber a note it read earlier.

The other useful boundary is provenance. If multiple agents share the same memory, each note or edit probably needs at least source client, timestamp, and reason/task id metadata. Otherwise the memory becomes portable, but debugging "why does every agent now believe this?" is still hard.

Disclosure: I work on Armorer Labs.