citetrail
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@citetrailfind where I read about retry backoff"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Citetrail
Local, provenance-backed memory of what your browser saw — every recall carries the URL, title, and timestamp it came from.
Citetrail captures the pages you actually read, keeps them on your machine, and makes them searchable — by you, and by your AI agents over MCP. When an agent uses something it found there, it can cite exactly where it came from.
Status: pre-release. See Project status before installing.
License: Apache-2.0
Local by default. No account, no server, no upload. Blocked pages fail closed.
The problem Citetrail solves
You read six tabs, closed them, and now your coding agent needs the thing in tab four. Your options today are: paste it again, let the agent re-search the open web and hope it lands on the same page, or accept an answer with no source.
Browser history knows you visited a URL. It does not know what the page said, and it cannot tell your agent. Citetrail closes that gap:
Browser history | Citetrail |
A list of URLs | The content you actually read, captured |
Search by title, roughly | Search by what the page said |
Invisible to your tools | Queryable by agents over MCP |
No notion of "why is this here" | Every entry carries its provenance |
Everything, indiscriminately | Only allowed pages; blocklist fails closed |
Related MCP server: qsearch
What "provenance-backed" means here
Every stored fragment keeps a bounded reference: source URL, page title, capture timestamp, and the position within the page. Recall returns the fragment and that reference together — they cannot be separated. An agent that answers from Citetrail can always say where it got it, and you can always open the original.
If the source is gone, Citetrail says the source is gone. It does not quietly serve a fragment as if it were still live.
Quickstart
git clone https://github.com/anonb3ll/citetrail
cd citetrail
python3 -m venv .venv
.venv/bin/pip install -e .
.venv/bin/citetrail init
# 2. Search the local store
.venv/bin/citetrail search "retry backoff"
# Optional: block a sensitive hostname before it can be stored
.venv/bin/citetrail block bank.example.test
# 3. Point an agent at the same local store over MCP
.venv/bin/citetrail mcp --stdioThe default store is ~/.local/share/citetrail. Set CITETRAIL_STORE or pass
--store PATH to use a different local directory. See
docs/extension.md to load the unpacked Chromium adapter.
Documentation
Guide | Description |
Documentation index | |
CLI commands and store layout | |
MCP tool schema and registration | |
Chromium extension setup | |
Blocklist and fail-closed behavior | |
Optional Runroom integration |
Frequently asked questions
How do I let my AI agent search my browsing history?
Run the local MCP server and register it with your agent. The agent queries Citetrail like any other MCP tool and receives fragments with their sources attached. It never gets raw access to your browser or your profile.
Where is my data stored, and does anything get uploaded?
On your machine, in a local database you can delete at any time. Citetrail has no server and performs no uploads. See docs/privacy.md.
How do I stop it capturing my bank, my email, or my work intranet?
The blocklist. It is checked before capture, and it fails closed — if the
rules cannot be evaluated for a page, that page is not captured. Add a host
with citetrail block bank.example.test. Allowlist-only capture is deferred.
Can an agent cite a source it did not actually read?
Not from Citetrail. The reference travels with the fragment; there is no API that returns text without its provenance.
What happens when I am offline, or a page is gone?
Recall works offline against what you already captured. If the original URL is unreachable, results are marked as such rather than silently presented as current. Unavailable and privacy-blocked states are reported honestly, not hidden.
Is this a note-taking app or a second brain?
No. Citetrail captures and recalls; it does not organize your thinking, build a knowledge graph, or ask you to maintain anything. It is plumbing for tools that need to know what you read.
Does it work in any browser?
The extension targets Chromium-based browsers first. The native bridge between the extension and the local service has real limits — see docs/limitations.md.
What Citetrail is not
Not a hosted service and not a sync service. One machine, one store.
Not a PKM or note system.
Not a clinical, wellbeing, or attention-tracking tool. It makes no claim about your cognition.
Not a scraper. It captures pages you visited yourself, under your rules.
Not a mobile app.
See docs/limitations.md and docs/private-exclusions.md.
Related project
Runroom coordinates handoffs between AI agents and humans with review gates and an audit trail. The two projects are independent and neither requires the other; an optional integration shows a Citetrail reference feeding a governed Runroom task.
Contributing
Read CONTRIBUTING.md and CODE_OF_CONDUCT.md. Report vulnerabilities privately — see SECURITY.md.
To run lint and tests after a cold install, use the dev extra (pytest and ruff
are not in the default install):
python3 -m venv .venv && .venv/bin/pip install -e ".[dev]"
.venv/bin/ruff check . && .venv/bin/ruff format --check . && .venv/bin/pytest -qA plain pip install -e . is enough for the Quickstart CLI above.
Project status
Pre-release, pre-1.0. Interfaces will change. Citetrail is published to find out whether other people need this — if you try it, tell us what you were trying to recall and whether you got it.
License
Apache License 2.0. Copyright 2026 The Citetrail Contributors.
Available Tools
1 toolcitetrail_searchC
Search local captures with inseparable provenance.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| source_state | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Search' implies a read-only operation, but the description does not clarify what 'inseparable provenance' means, how results are returned, whether source_state affects behavior, or what happens when captures are unavailable or privacy-blocked. This is a minimal signal rather than transparent behavior.
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 a single short sentence with no filler or repetition. The core action and resource are front-loaded. It is appropriately concise, though the cryptic 'inseparable provenance' could have been replaced with more useful information without harming length.
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?
The tool is relatively simple with only two parameters, but there is no output schema, no annotations, and no parameter-level documentation. The description leaves critical details undefined: what 'local captures' are, what 'inseparable provenance' means, how query matching works, and what the response shape is. This is not enough for an agent to reliably invoke the tool correctly.
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 description coverage is 0%, and the description provides no information about either parameter. 'query' and 'source_state' are completely undocumented, and the meaning of the source_state enum values is left entirely to inference. The description fails to compensate for the schema's lack of 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?
The description clearly states a search operation over 'local captures,' which identifies the tool's verb and resource. The phrase 'with inseparable provenance' adds a distinguishing quality, though it is jargon-heavy and not fully explained. With no sibling tools to differentiate from, this is clear enough for basic selection.
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 the tool should be used when searching local captures, giving some usage context. However, it provides no explicit guidance on when to prefer this tool over alternatives, no prerequisites, and no exclusions. The usage signal is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
citetrail_search
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The purpose of citetrail_search is singular and unambiguous.
The single tool name 'citetrail_search' follows a clear object-action pattern, and with only one tool there is no inconsistency to evaluate.
A single search tool feels insufficient for a server named 'citetrail', which implies a broader capture management lifecycle. One tool is too thin for the apparent scope of the domain.
The server only exposes search; there are no create, retrieve, update, delete, or list operations for captures. This leaves agents unable to ingest or manage captures, creating significant gaps and dead ends.
Maintenance
Related MCP Connectors
Scrape, crawl and search the web for AI agents via MCP.
- KogniteOAuthdev.kognite
Hosted agent memory: store, search, and recall facts across sessions from any MCP client.
Agentic search over your Dewey document collections from any MCP-compatible client.
Persistent memory for AI agents — log and recall conversation context over MCP.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI tools to query a user's private, locally stored memories (notes, documents) with source citations, using the MCP protocol.10 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to perform web searches with full content retrieval and multi-engine provenance, including trust scoring and local corpus persistence, via MCP integration.3 npm2Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables LLM agents to perform web search, scraping, and summarization outside their context window, receiving compact cited briefs via MCP while full pages are cached and viewable in a local web UI.MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to perform web research over MCP: search with a real browser, fetch JS-rendered pages, download PDFs and convert them to Markdown, then search and page through large documents using bounded previews so the context window isn't flooded.BSD Zero Clause