Magpie Search MCP server

<!-- mcp-name: io.github.xfloukiex-lab/magpie-search -->

Magpie Search

A federated search engine — the search engine an AI agent or LLM reaches for when it needs to find something true to reason over.

Ever had your computer reboot on you, or a power outage hit mid-session? Every thread your agent was holding — gone. Now you have the tool to get it back. Never forget what your agent lost again. Magpie indexes everything your AI has ever worked through, locally, so a crash is a hiccup instead of amnesia.

What Magpie is

A normal search engine looks in one place. Magpie takes one question and fans it across everything that matters at once — the AI's entire conversation history, the files on the machine, a structured knowledge graph, a vector store, and the live web — and pulls the answer back from wherever it actually lives. Five sources, one call.

And it searches each one the right way. It can grep for an exact string or regex when you know the precise token — a file path, an error, a line of code. It can search by keyword. It can search by meaning, so it finds the thing even when the words don't match. It can do all of that at once.

Then it does the part that makes it trustworthy: it fuses everything into a single ranked answer, and every result carries a trust tier — fact > reference > lead > stale. The solid sources rise, the loose ones are marked as leads to verify, duplicates collapse, and it's all trimmed to fit so it never floods the AI's context. Ask it to go deep and it expands one question into many, reads the pages, and tells you how many independent sources agree — a full research sweep without an army of agents.

It runs entirely on the machine. No server, no account, and no telemetry unless you turn it on. The AI's transcripts and files never leave. It plugs into whatever AI is running over MCP, so the agent can reach all six sources the instant it needs them.

It is a tool for an AI — an agent or an LLM.

What's inside

At its core is a local index of the AI's transcripts: a SQLite database with two structures built side by side —

small all-MiniLM-L6-v2 model.

• an FTS5 full-text index (BM25 keyword ranking), and
• a vector index (sqlite-vec) of 384-dim embeddings produced locally by a

Everything is redacted at ingest — a scrubber strips ~30 classes of secrets (keys, tokens, private keys, connection strings) before a single byte hits the index.

On top of that index sit the five search modes:

Around that sits the federation layer — the part that makes it federated:

Shortened. The full README is on GitHub.