MCP Read Later Server: Give Your AI Agent Your Entire Reading History

Your AI coding assistant knows your codebase. It knows the open web. It does not know what you've been reading.

That researcher article you saved last month about vector database benchmarks? It doesn't know about that. That case study on distributed tracing patterns you bookmarked for "later"? Gone. The newsletter deep-dive on LLM inference optimization you skimmed and forgot? Not accessible.

The Model Context Protocol (MCP) was designed to close this gap — and an MCP read later server is the specific bridge between your reading history and your AI agent's context window. This is how it works, why it matters, and how to set it up in under five minutes.

What is an MCP read later server?

An MCP read later server is a process that exposes your saved articles, bookmarks, and reading vault to any MCP-compatible AI client as structured, queryable tools. Instead of your reading history being a closed silo in one app, it becomes a real-time knowledge layer your AI assistant can search, summarize, and reason over during a conversation or coding session.

The Model Context Protocol, open-sourced by Anthropic in late 2024, is a standard interface for connecting AI clients to external tools and data. It's the equivalent of a REST API for agents: the server exposes tools with typed schemas, the AI client discovers those tools at connection time, and then calls them with structured arguments just like function calls. By 2026 it's become the de facto standard across the major AI coding environments — Claude Desktop, Claude Code, Cursor, Windsurf.

An MCP read later server applies this pattern to your reading history. Your bookmarks, article vaults, and saved content become MCP tools the AI can actively use — not just data you personally search when you remember to.

Why does your AI agent need your reading history?

Without access to your reading history, your AI agent operates on static world knowledge and whatever you paste into the conversation. It misses the domain-specific, recent, personally curated knowledge you've been accumulating.

Here's what changes when your reading history is connected:

Contextual research retrieval. You ask Claude to help you design a caching layer. Normally Claude answers from training data. With an MCP read later server, it can also query your vault: "What have you saved about caching?" and pull in your bookmarked articles on Redis patterns, CDN invalidation, and the distributed caching essay you saved three weeks ago. The answer is grounded in your specific research, not generic internet knowledge.

Triage-driven workflow. You're about to start a deep work session. Your AI agent can check what's pending in your read-later queue that's relevant to today's task — effectively doing the "what should I read before I start?" filter for you.

Knowledge continuity. Senior engineers have years of reading behind their intuitions. Junior engineers' AI assistants don't have access to that experience gap. An MCP read later server is one concrete way to close it — injecting your domain reading history into the model's context.

The alternative is copy-paste. Every time you want your AI to consider something you've read, you manually paste it in. An MCP server automates that entirely.

How does Burn 451's MCP read later server work?

Burn 451 ships a 26-tool MCP server that exposes your entire reading history — saved articles, vaults, sparks, tags, and triage state — to any connected AI client. Each tool has a typed input schema, consistent error handling, and scoped access so the AI can only read (not mutate) your library unless you grant write tools.

The server is stateless across restarts: it authenticates once using your BURN_MCP_TOKEN, caches the session to ~/.burn/mcp-session.json with restricted file permissions, and reuses that session on subsequent launches. Zero network calls on startup after the first auth.

Under the hood, each tool call hits Burn's REST API, applies server-side filtering and pagination, and returns structured JSON the AI client can reason over. The server runs as a local process — your reading data never passes through a third-party relay.

For the design decisions behind those 26 tools — why tool-first rather than resource-first, how progressive disclosure prevents tool-list overload, and how vault-scoped queries balance breadth against response latency — see Building Burn's MCP Server: 3 Patterns That Actually Work.

How do I set up Burn's MCP read later server?

Setup takes under five minutes: install Burn 451, get your MCP token, and run one command. No config files, no Docker, no port management.

Step 1: Create a Burn 451 account

Sign up at burn451.cloud — it's free, no credit card required. Install the iOS app or Chrome extension to start saving articles.

Step 2: Get your MCP token

In the Burn web app: Settings → MCP Server → Generate Token. Copy the token — it's a long-lived credential you'll use as an environment variable.

Step 3: Set the environment variable

export BURN_MCP_TOKEN=your_token_here

For a permanent setup, add it to your shell profile (~/.zshrc, ~/.bashrc, or your system's env manager).

Step 4: Test the server

npx burn-mcp-server

You should see the server start and list its available tools. That's it.

Step 5: Connect to your AI client

Claude Desktop — add to claude_desktop_config.json:

{
  "mcpServers": {
    "burn": {
      "command": "npx",
      "args": ["burn-mcp-server"],
      "env": {
        "BURN_MCP_TOKEN": "your_token_here"
      }
    }
  }
}

Claude Code — add to your project's .claude/settings.json under mcpServers with the same structure.

Cursor — in Settings → MCP → Add Server, point it at npx burn-mcp-server with the token in environment.

Windsurf — same pattern: MCP settings, command npx burn-mcp-server, env token.

Once connected, restart your client and confirm the burn tools appear in the available tools list.

What tools does the MCP read later server expose?

The 26 tools cover four categories: search and retrieval, triage and status, vault management, and analytics. Most read-later use cases hit just a handful:

Most-used tools:

Less common but powerful:

• •get_ash — recently burned articles (recovery window still open)
• •search_by_domain — all articles from a specific site (e.g., "show me everything I've saved from arxiv")
• •get_reading_stats — your processing cadence, topic distribution, retention rate

The server separates read tools (safe to always enable) from write tools (save_to_vault, burn_article, move_to_spark) which require explicit opt-in. For most AI coding workflows, read-only access is sufficient.

Which AI clients work with Burn's MCP server?

Any MCP 1.0-compatible client works without modification. As of May 2026, that includes Claude Desktop, Claude Code (the CLI), Cursor, Windsurf, and any application built on the official MCP SDK.

A few notes on each:

Claude Code is the most natural fit. You're already in the terminal, the server starts alongside your session, and asking Claude to query your reading history mid-task feels seamless. If you've saved articles about the library you're implementing, Claude can surface them without you context-switching.

Cursor works well for reference lookups — "show me my saved articles about this pattern" during a code review session. The tool panel in Cursor's sidebar surfaces MCP tools directly.

Claude Desktop is useful for research sessions outside of coding — drafting, analysis, writing. Having your vault accessible during a writing session is different from having it in your IDE, but equally useful.

One client that doesn't yet support MCP natively: ChatGPT. If you need ChatGPT integration, the Burn REST API is available and you can build a custom GPT action, but that's not a one-command setup.

How is an MCP read later server different from a bookmarks API?

A bookmarks API requires you to know what to search for. An MCP server lets the AI decide when to query your reading history and what questions to ask. The agency is reversed.

With a REST API, you write code like: GET /api/articles?tag=caching — and you get back a list. Useful, but you have to know to ask, you have to write the integration, and you have to invoke it manually.

With an MCP server, the AI agent has access to the schema of your entire reading library at all times. When you ask Claude to "help me implement a write-through cache," it can autonomously decide: "I should check if the user has any saved articles on this topic first" — call search_vault("write-through cache") — and incorporate your specific saved research into its answer without you prompting it.

That autonomous query loop is the difference. The AI isn't passively waiting for you to paste in content. It's actively using your reading as a knowledge source during the task.

FAQ

Is Burn 451's MCP server free?

Yes. The MCP server (burn-mcp-server on npm) is free and open source. Burn 451 itself is also free — all features, including MCP access, AI digest, and unlimited saves.

Does the MCP server send my reading data to a third party?

No. The npx burn-mcp-server process runs locally on your machine and communicates directly with Burn's API. Your reading data goes from Burn's servers → your local MCP server process → your local AI client. No third-party relay.

Can I use the MCP server without saving articles through Burn's apps?

You need a Burn account with at least some saved articles for the tools to return useful results. You can save via CLI (burn save <url>), browser extension, or iOS share extension. There's no minimum — even 10 saved articles gives you a working knowledge layer.

What's the difference between this and building my own read-later MCP server?

Rolling your own means maintaining auth, pagination, schema design, tool count management, and client compatibility as MCP evolves. Burn's server handles all of that. If you prefer full control, the source code is open — fork it and point it at your own data store.

How do I keep the server updated?

npx burn-mcp-server always pulls the latest published version. For a pinned version, use npx burn-mcp-server@x.y.z. Breaking changes are rare — MCP tool schemas are versioned and the server maintains backward compatibility with the previous minor version.

Does this work with the Anthropic Agent SDK?

Yes. Any code that initialises an MCP client using the official Anthropic SDK can connect to burn-mcp-server and call its tools. The server speaks standard MCP 1.0 — no special Burn-specific SDK required.

Start Using Your Reading as AI Context

You've been building a reading history for years. An MCP read later server is the bridge that makes it useful inside your AI workflows — not just sitting in an app you open occasionally.

Setup: five minutes. The payoff is every time your AI agent surfaces something you've already read — instead of you having to remember it exists.

[Set up Burn 451 free](https://www.burn451.cloud?ref=blog-mcp-read-later-server) — or jump straight to the technical companion: Building Burn's MCP Server: 3 Patterns That Actually Work.