Hydrate memory is now on Gemini CLI. One binary. Proven end-to-end.

I asked Gemini CLI about a project I have been building in Claude Code.

It called hydrate_recall and got back: "The database name is 'postgres', and the schema name is 'civichub'."

That is a fact I told Claude Code weeks ago. Gemini retrieved it. Different company. Different model. No mocks.

hydrate-mcp shipped today. One Go binary. Every MCP-capable agent gets Hydrate memory.

Why MCP and not a bespoke Gemini plugin:

Every agentic tool has its own plugin surface. Writing one per tool is a tax you pay forever.

MCP skips it. One binary, three tools (hydrate_recall, hydrate_save_fact, hydrate_list_projects), one protocol. Already works on Gemini CLI, Cursor, Cline, Continue, Windsurf, Zed, Claude Desktop.

~500 lines of Go. MIT.

hydrate-mcp shipped today. One Go binary. Every MCP-compatible agent gets Hydrate memory.

I tested it on Gemini CLI before writing this post. I asked it about a project I have been building in Claude Code for the past few weeks. It called the hydrate_recall tool and got back: "The database name is 'postgres', and the schema name is 'civichub'." That is a fact I told Claude Code. Gemini retrieved it. End-to-end, no mocks.

The architecture is deliberately minimal: three MCP tools over stdio, about 500 lines of Go total. hydrate_recall takes a query and returns relevant facts. hydrate_save_fact writes a new fact. hydrate_list_projects shows what is in the store.

The reason for MCP rather than a bespoke Gemini integration: every agentic tool has its own plugin surface. Cursor has extensions. Cline has its own. Windsurf, Continue, Zed, Claude Desktop. Writing one integration per tool means six moving targets. MCP is one protocol. The binary works on anything that speaks it.

The trade-off worth being honest about: Gemini CLI does not have an equivalent to Claude Code's UserPromptSubmit hook, so context injection is not automatic. You ask explicitly (hydrate_recall). Claude Code users get passive injection. Gemini CLI users get active retrieval. Both work. They are different UX patterns for the same store.

Full write-up: gethydrate.dev/blog/hydrate-on-gemini-cli

I asked Gemini CLI about a Claude Code project.

It recalled: "The database name is 'postgres', schema is 'civichub'."

Different company. Different model. Same Hydrate store. One Go binary, three MCP tools.

Title

hydrate-mcp: one Go binary that gives any MCP-capable agent access to your Hydrate memory store

Body

Just shipped hydrate-mcp. It exposes a Hydrate fact store as three MCP tools over stdio: hydrate_recall, hydrate_save_fact, hydrate_list_projects. About 500 lines of Go, MIT licensed.

Tested it on Gemini CLI this morning. Asked it about a project I have been building in Claude Code for the past few weeks. It called hydrate_recall and retrieved the database name and schema correctly. That fact was written during a Claude Code session. Gemini retrieved it. Cross-vendor, end-to-end, no mocks.

Why MCP rather than a bespoke Gemini plugin: every agentic tool has its own plugin surface and writing one per tool is a maintenance tax. MCP is one protocol. The same binary works on Gemini CLI, Cursor, Cline, Continue.dev, Windsurf, Zed, and Claude Desktop.

The honest trade-off: Claude Code has a UserPromptSubmit hook, so Hydrate can inject context passively before every prompt. Gemini CLI does not have an equivalent hook, so you retrieve explicitly. Different UX, same store.

Happy to answer questions about the MCP implementation or the tool schema.

Title

hydrate-mcp: cross-vendor AI memory via MCP (Claude Code store retrieved by Gemini CLI)

URL

https://gethydrate.dev/blog/hydrate-on-gemini-cli

First comment

Author here. The headline claim is that a fact written during a Claude Code session can be retrieved by Gemini CLI via MCP. I tested this before posting: asked Gemini CLI about a project I had been building in Claude Code, it called hydrate_recall and got back the correct database name and schema. Different company, different underlying model, same MCP binary.

The implementation is deliberately minimal: about 500 lines of Go, three tools (recall, save, list), MCP over stdio. The store is SQLite on disk. Nothing leaves the machine.

The architecture decision worth questioning: why not just a Gemini plugin, or a Cursor extension, or a Cline integration? The answer is that every agentic tool has its own plugin surface. MCP is one protocol that most of these tools now speak. One binary reaches all of them. The trade-off is that you get the lowest common denominator of what MCP supports, which means no passive injection on Gemini CLI (no UserPromptSubmit equivalent). You retrieve explicitly.

Happy to go into the implementation details or the decision to use SQLite over a vector store (short answer: for this use case, keyword and semantic search on a few thousand facts is fast enough without the operational overhead).