Allows searching YouTube videos and incorporates results into the federated search alongside other sources.
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.
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.
Related MCP server: wigolo
At its core is a local index of the AI's transcripts: a SQLite database with two structures built side by side —
an FTS5 full-text index (BM25 keyword ranking), and
a vector index (sqlite-vec) of 384-dim embeddings produced locally by a
small all-MiniLM-L6-v2 model.
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:
Mode | What it does |
| literal / regex match (exact tokens: paths, errors, code) |
| FTS5 / BM25 keyword |
| embedding K-NN, cosine distance in the vector index |
| lexical + semantic fused by RRF |
| hybrid, then a cross-encoder (jina-reranker) re-scores each candidate |
Around that sits the federation layer — the part that makes it federated:
A provider plugin system. Five backends (transcripts, files, knowledge
graph, vector, web), each returns Hit objects tagged with a trust
tier.
A fan-out: one query goes to all providers concurrently (≤8 workers), each with a 5-second timeout that fails open — a slow source contributes nothing rather than blocking the call.
Trust-weighted RRF fusion — Reciprocal Rank Fusion where each source's rank
is multiplied by its trust weight (fact ×3, reference ×2, lead ×1, stale ×0.3), damping constant 60. This is the math that merges six heterogeneous
sources into one honest ranking.
Cross-source dedup by content hash — the same fact found in three places collapses to one hit, tagged with where else it appeared (corroboration).
A token-budget trim, so the merged set never overflows the calling AI's context.
And it exposes all of this to an AI over an MCP server — the tools it hands
an agent are exactly: search, recent, session, list_sessions, stats,
reindex. Note what's not in that list: nothing that writes an answer.
RAG = Retrieval-Augmented Generation. It's a two-stage pipeline, and the defining stage is the second one: a retriever finds chunks → they're stuffed into a prompt → a language model generates the prose answer. The "G" is the whole point of the name; without a generator writing the answer, it isn't RAG.
Magpie has no G:
There is no generator anywhere in the search path. Nothing in Magpie composes a natural-language answer. The closest thing to a model — the cross-encoder reranker — outputs a relevance number per result and reorders the list. It scores; it never writes a sentence.
It stops at "here are the ranked hits." A RAG owns the prompt assembly and the model call. Magpie returns the fused, trust-ranked results and hands them back through MCP. What the AI does next — whether it even generates anything — is the AI's job, outside Magpie.
Its retriever is more than a RAG's retriever, not less. A textbook RAG retriever is one vector store: embed the query, top-k by cosine, done. Magpie's retrieval is six sources, five modes, trust-weighted fusion, cross-source dedup. It's a far more capable "R" — but it's still only the R.
Plug Magpie into an AI and the pair can form a RAG — Magpie is the R, the AI you bring is the G. But Magpie by itself ships only the R, and a stronger R than usual. It finds and ranks the truth; it never generates the answer.
The expensive part of "deep research" is reasoning, and the multi-agent approach pays for it N times over — one full LLM context per agent, often millions of tokens for a single question. But reasoning doesn't need to fan out; one capable model already in context can synthesize. Only the searching needs breadth — and searching the web is pure retrieval, zero LLM tokens.
magpie-search deepweb is built on that asymmetry. It fires several sub-queries
at the web in parallel, fuses them by trust-weighted RRF + dedup-by-URL into one
compact, token-budget-trimmed source set, optionally reads the top pages' text
(still token-free), and reports how many independent domains corroborate the
result — an agent-free version of the verification a research swarm pays agents
to do.
So you get the breadth, page-reading, and corroboration of a multi-agent deep search, but your model only pays for a single synthesis pass over a trimmed result set.
Token cost, measured — one deep question:
Approach | Tokens the model pays |
Multi-agent deep-research swarm (N agents each read pages into their own context) | ~2,000,000 |
| ~1,050 |
That's ~2,000× fewer tokens — about 1/2000th the cost — because the searching and page-reading are pure retrieval (zero model tokens); your model only does the final synthesis pass over the trimmed, corroborated set.
# one question, several angles, read the top pages — all token-free retrieval
magpie-search deepweb "the question" --q "another angle" --q "a third angle" --thoroughThe model in your loop then does one synthesis pass over the merged, corroborated set. That's the whole saving: the breadth is free, you pay only for the answer.
pip install magpie-searchOr install the latest straight from source (pulls all dependencies):
pip install "git+https://github.com/xfloukiex-lab/magpie-search.git"Optional — add the local-LLM features (the cross-encoder reranker runs on the base install; the session summarizer needs Ollama):
# 1. Install Ollama (free, runs entirely locally) — https://ollama.com/download
# 2. Pull the model magpie-search uses
ollama pull phi3.5Python 3.10+ on Windows, macOS, and Linux.
magpie-search index # build the index (incremental)
magpie-search search "that retry backoff thing" # keyword search
magpie-search search --mode hybrid "..." # keyword + semantic, fused
magpie-search search --mode rerank "..." # + cross-encoder rerank
magpie-search stats # sanity-check the indexMagpie speaks the Model Context Protocol, so any MCP-capable agent can call it. Point your client at the bundled server:
// e.g. an MCP client config
{
"mcpServers": {
"magpie": { "command": "magpie-search-mcp" }
}
}The agent then has search, recent, session, list_sessions, stats, and
reindex available — federated, trust-ranked, context-budgeted.
Command | What |
| Incremental indexing pass over |
| Search — |
| Latest 30 messages of the newest session |
| Full transcript of one session |
| Recent sessions |
| Index size, last-indexed time, row counts |
| Back up |
Add --help to any command for full options.
import magpie_search
results = magpie_search.search("retry backoff", mode="hybrid", k=5)
for h in results["hits"]:
print(h["trust"], h["source"], h["snippet"])
# LLM features (needs Ollama + phi3.5)
import magpie_search.llm
ranked = magpie_search.llm.search_rerank(query="retry backoff", k=3, pool=10)
summary = magpie_search.llm.summarize(session_id="abc-123", n_messages=80)magpie-search backup copies your transcript tree to a destination of your
choice — a local folder (default, zero config), a remote SSH target (NAS / home
server), or a remote SSH target with VM boot/suspend. Configure it in
~/.magpie-search/backup.env:
MAGPIE_SEARCH_BACKUP_SSH_HOST=user@nas.local
MAGPIE_SEARCH_BACKUP_SSH_DEST=~/claude-transcripts/Useful flags: --dry-run, --no-suspend, --show-config. Backup copies; it
never deletes originals.
Everything is environment-variable driven with sensible defaults.
Var | Default | What |
|
| Data directory (DB, models, logs) |
|
| fastembed model cache |
|
| Ollama server URL |
| heuristic | Set to |
|
| Per-call audit log |
The summarizer passes through a 6-probe guardrail stack (length,
proper-noun-safety, identifier-safety, refusal-drift, semantic-grounding,
self-verify); all six must pass for trust: clean. Any failure suppresses the
summary and returns trust: degraded — quiet over wrong. Raw messages stay
accessible via magpie-search session SESSION-ID.
Magpie Search is a local tool. No server, no account, no auto-update, no crash reporter, and no telemetry unless you explicitly opt in (see below). Your transcripts, the index, the audit log, the model cache, and the backups all live on your machine.
Opt-in telemetry. Telemetry is off by default — magpie sends nothing
until you run magpie-search telemetry enable (or set
MAGPIE_SEARCH_TELEMETRY=1). When on, it sends only anonymous usage: which
command ran, search mode, result/hit counts, latency, error class, and your
magpie/python/OS versions, tagged with a random install id. It never sends
your queries, file paths, results, transcript content, username, or IP — a
hard content firewall in telemetry.py drops anything that isn't a number or a
short enum token. Disable anytime with magpie-search telemetry disable; check
state with magpie-search telemetry status. The only
network calls it ever makes are: your local Ollama server (LLM features), your
own backup target (only when you run backup), and a one-time model download
from Hugging Face on first run. Verify it yourself with tcpdump, Wireshark, or
a network-blocked sandbox.
Run magpie-search index (and optionally backup) on a schedule. Ready-made
units live in installers/ for systemd (Linux), launchd (macOS),
and Task Scheduler (Windows).
"rsync not on PATH" — falls back to scp -r. On Windows, install
Git for Windows, which ships rsync.
Search returns nothing — run magpie-search stats; if last_indexed_at is
null, run magpie-search index.
Summarizer always degraded — that's the false-positive guard working as
designed. Raw transcripts remain available via session SESSION-ID.
Magpie Search is built by VektorGeist LLC.
We build local-first tools for people who run their own AI. Magpie is the search core; our agent platform is at vektorgeist.com.
Website: vektorgeist.com
Contact: floukie@vektorgeist.com
Issues & contributions: open an issue or PR on this repository.
Licensed under the Apache License 2.0 — see LICENSE. Copyright © 2026 VektorGeist LLC.
"Magpie Search" and the magpie mark are trademarks of VektorGeist LLC. The code is open under Apache-2.0; the brand and name are reserved.
List the most-recent Claude Code sessions (conversations) in the index, newest first. This is the browse/discovery entry point: use it to find out what sessions exist and get their session_id values before calling 'session' (read one in full) or 'recent' (latest messages). Prefer 'search' when you are looking for specific content rather than browsing. Returns one row per session — session_id, project, message count, and last-activity time. Read-only; never modifies the index.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | only list sessions in this project slug | |
| limit | No | max sessions to return, newest first (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only; never modifies the index.' Since no annotations are provided, the description fully handles behavioral disclosure. It also describes the output fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four focused sentences, front-loaded with the core action, and each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, return format, usage context with siblings, and behavioral safety. No output schema exists, but the description explicitly states what is returned, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described in the input schema. The description mentions 'project' and 'limit' but does not add new meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the most-recent sessions newest first, and distinguishes itself from siblings by positioning it as the browse/discovery entry point, explicitly saying to use 'search' for specific content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: use it to discover sessions and get session_id before calling 'session' or 'recent', and prefer 'search' when looking for specific content. It also implies this is for browsing, not for direct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the most-recent messages across the index, newest first. Use this to catch up on the latest activity ("what was discussed most recently?") without a search query. To read one specific known session in order, prefer the 'session' tool instead. Optionally narrow to a single session or project. Read-only; each row includes its text, session id, and timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | number of most-recent messages to return (default 50) | |
| session_id | No | only messages from this session id | |
| project | No | only messages from this project slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares read-only behavior and describes return fields (text, session id, timestamp). Without annotations, this provides adequate behavioral context, though no mention of limits or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two main sentences plus a note on read-only and return fields. No superfluous text, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description covers purpose, filtering, and return fields. Lacks mention of sorting details or error handling, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds minimal value. It mentions optional filtering but does not add details beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns most-recent messages, newest first. Distinct from sibling 'session' tool, which is for reading a specific session in order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (catch up on latest activity without a search) and when to prefer an alternative (use 'session' for a specific known session).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one incremental indexing pass so search is fresh. Local-only; reads ~/.claude/projects transcripts.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | override projects dir |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is incremental, local-only, and reads from a specific directory. However, it does not detail side effects, safety, or whether it can be run frequently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It is front-loaded with the action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose, default behavior, and local scope. It could mention the return or effect more explicitly, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description 'override projects dir' is provided in the schema. The tool description adds context by noting the default path, but adds little beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and the resource 'incremental indexing pass' with the purpose of refreshing search. It distinguishes itself from sibling tools like list_sessions, search, etc., which do not perform indexing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when search freshness is needed, but lacks explicit guidance on when not to use or alternatives. It does mention 'Local-only' as a constraint, which is helpful but insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search indexed Claude Code transcripts. Returns top-k matching message snippets. Results are leads to verify, never authoritative fact. Pass 'sources' to fan out across multiple backends (e.g. transcripts + files + plugins): results are then tagged with source + trust tier and trimmed to a token budget.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | search text | |
| k | No | max results (default 10) | |
| mode | No | ranking strategy (default lexical); single-source only | |
| project | No | filter to a project slug | |
| role | No | filter by role (user/assistant) | |
| dedup | No | collapse duplicate clusters | |
| sources | No | multi-source: provider names to fan out across, e.g. ['transcripts','files'] | |
| budget_tokens | No | token budget for merged result (multi-source only) | |
| min_trust | No | drop hits below this trust tier (multi-source only) | |
| scope | No | narrow sources, e.g. a project slug or a subpath (multi-source only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that results are non-authoritative leads and explains multi-source behavior (fan-out, source tagging, trust tiers, token budget). However, it does not mention ordering, pagination, error behavior, or performance characteristics, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three well-structured sentences. The first defines core function, the second adds a critical caveat, and the third explains advanced multi-source usage. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (10 params, multiple modes, multi-source), the description covers the key functionality and important use cases. However, it lacks details on output format (e.g., snippet structure, metadata) and does not specify ordering or error handling, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that 'sources' fans out across backends and that 'mode' is only for single-source queries. This goes beyond the schema descriptions, justifying a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches indexed Claude Code transcripts and returns top-k matching message snippets. It distinguishes from sibling tools (list_sessions, recent, reindex, session, stats) which focus on session management or indexing, not content search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: results are leads to verify, never authoritative fact. It explains when to use the 'sources' parameter for multi-source fan-out. However, it does not explicitly contrast with sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one full conversation in chronological order, oldest message first, a page at a time. Use after you already have a session_id (from 'list_sessions' or a 'search' hit) and want to read that whole session in order rather than search across many. Page through long sessions with limit/offset. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | id of the session to read (from 'list_sessions' or a search result) | |
| limit | No | messages per page (default 200) | |
| offset | No | messages to skip from the start, for paging (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, chronological order, and paging behavior. Without annotations, it adequately covers behavioral traits but could be more explicit about error handling or return format. Still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences front-loaded with main purpose, no fluff. Every sentence adds value: purpose, usage context, paging, read-only nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple read tool with no output schema. Covers all needed aspects: what it does, when to use, how to page, safety (read-only). No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by explaining the purpose of session_id (from list_sessions/search) and the roles of limit/offset for paging. Schema already covers descriptions, but description enhances context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a full conversation in chronological order, specifying the verb (read), resource (conversation/session), and ordering. It distinguishes from siblings by mentioning using session_id from list_sessions or search and contrasting with searching across many.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: after having a session_id from list_sessions or search, and wanting to read a whole session in order rather than searching across many. Provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Index health summary (message/session counts, coverage).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It states the tool returns a summary, which likely is read-only and non-destructive, but does not explicitly confirm this or disclose any potential side effects, performance implications, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, front-loads the key information ('Index health summary'), and specifies exact metrics. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is adequate but could be more complete by describing the return format (e.g., JSON structure, whether it returns aggregate or per-index stats). It does not explain coverage scope or interpretation, which may be needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage. The description does not need to add parameter details. Baseline is 4, and no additional value is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an 'index health summary' with specific metrics: message/session counts and coverage. This is distinct from sibling tools like list_sessions (lists sessions), recent (recent items), reindex (performs reindexing), search (search query), and session (specific session operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining health statistics, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention conditions for use or non-use. The purpose is clear, but the lack of exclusions or comparisons leaves some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.1list_sessions2 fields changedInput schema / properties / limit / descriptionPrevious value: -"default 50"New value: +"max sessions to return, newest first (default 50)"Input schema / properties / project / descriptionAdded value: +"only list sessions in this project slug"recent3 fields changedInput schema / properties / n / descriptionPrevious value: -"message count (default 50)"New value: +"number of most-recent messages to return (default 50)"Input schema / properties / project / descriptionAdded value: +"only messages from this project slug"Input schema / properties / session_id / descriptionAdded value: +"only messages from this session id"session3 fields changedInput schema / properties / limit / descriptionPrevious value: -"default 200"New value: +"messages per page (default 200)"Input schema / properties / offset / descriptionPrevious value: -"default 0"New value: +"messages to skip from the start, for paging (default 0)"Input schema / properties / session_id / descriptionAdded value: +"id of the session to read (from 'list_sessions' or a search result)"v0.1.0list_sessionsrecentreindexsearchsessionstatsEach tool targets a distinct operation: listing sessions, recent messages, reindexing, searching, reading a full session, and stats. Descriptions clearly differentiate them, minimizing confusion.
Names include verb_noun (list_sessions), verbs (search, reindex), nouns (session, stats), and an adjective (recent). No consistent pattern, but they are short and intuitive.
6 tools cover the essential operations for browsing, searching, and reading sessions without being excessive. Well-scoped for the server's purpose.
The set covers session discovery (list_sessions, recent), content retrieval (search, session), maintenance (reindex), and health checks (stats). No obvious gaps for a read-only session browser.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Agentic search over your Dewey document collections from any MCP-compatible client.
Self-hosted AI-native knowledge workspace with hybrid search, GraphRAG, and MCP.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xfloukiex-lab/magpie-search'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
