How to give AI agents local work history through MCP
A practical way to share research and desktop work context with Claude Code, Codex, and other MCP clients—without treating a chat transcript as the whole story.
この記事を日本語で読む →
MCP is the way out of a memory silo
MCP gives compatible clients a common way to request context from an external source. Contextberg keeps desktop activity, browser history, and agent conversations on the user's computer, then exposes selected work context to clients such as Claude Code and Codex.
A useful memory system needs more than storage. If the agent you use next cannot retrieve the relevant part of your previous work, that memory does little for the task. The aim is a shared entry point rather than a separate integration for every agent.
The desktop app owns the history
Contextberg's desktop app provides a local API. A small MCP bridge connects that API to an MCP client. The bridge is not where your screenshots or work history live; it translates the client's request into a local request to the app.
Keeping those roles separate makes the boundary easier to understand: the desktop app manages local data and recording controls, while the MCP bridge handles the protocol used by the agent.
Ask for the right layer of memory
A recent activity query helps with a short interruption. A daily report helps reconstruct a day. Long-term memory is for durable project assumptions. Agent history can show what was discussed in an earlier coding session.
Those are different questions, so they should not all return one giant transcript. A small answer with a clear time range is easier to inspect and correct than a raw dump of everything recorded.
Research history is part of the handoff
The useful question is not merely which URLs were opened. It is which sources informed a decision, in what order, and which alternatives were set aside. Browser history is a clue, not proof that a page was read or accepted.
| Moment | Context to retrieve | What the next agent can do |
|---|---|---|
| After reading documentation | Page, API version, and relevant constraints | Check the proposed change against the specification |
| After following an issue | Issue status and possible workaround | Avoid repeating a known failure |
| After inspecting logs | Error time, preceding action, and reproduction steps | Prioritize plausible causes |
| After comparing approaches | Options, rejected paths, and decision criteria | Continue without restarting the same debate |
A prompt for the next session
Summarize the official documentation, GitHub issues, and other pages I consulted in the last two hours.
Separate evidence relevant to the current implementation from pages that may not matter.
Then list three risks to check before I proceed.Check the cited pages and the proposed risks yourself. A work-memory tool can help recover the trail, but it cannot establish that every page was read or that an earlier conclusion was correct.