How do I use digital-brain?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@digital-brain find pages about RAG techniques from last week" 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.

digital-brain

by ArpitaSethi-12

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

What was I working on yesterday related to RAG?
Which website did I spend the most time on last week?
What was that command I copied to clear the terminal?

Digital Brain captures your Chrome browsing activity — page visits, text selections, copy/paste events, page content, and time spent — stores it 100% locally, and lets you search and ask questions using AI. It combines keyword search (SQLite FTS5) with semantic search (ChromaDB vectors) through a RAG pipeline powered by a local LLM.

✨ Features

Feature	Description
🧩 Chrome Extension	Captures page visits, selections, copy/paste, page content, and tab focus time
⚡ FastAPI Backend	Receives, stores, and indexes events locally on `localhost:8420`
🔍 Full-Text Search	SQLite FTS5 keyword search with highlighted snippets and filters
🧬 Vector Search	ChromaDB semantic indexing for meaning-based recall
🤖 RAG Q&A	Ask questions in plain English — uses local LLM to generate answers
📊 Activity Stats	Top domains by time spent, daily breakdowns, and event timelines
💻 CLI Tool	Rich terminal interface with `brain search`, `brain ask`, `brain stats`
🔌 MCP Server	Query your history from Claude Desktop, VS Code, or any MCP client
🛡️ Privacy-First	All data stays on your machine — no cloud, no tracking

Related MCP server: Chrome History & Bookmarks MCP Server

📐 Architecture

┌──────────────────────────────────────────────────────────────────────┐
│                         Chrome Browser                               │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │  Chrome Extension (Manifest V3)                                │  │
│  │  ┌─────────────┐  ┌────────────────┐  ┌───────────────────┐   │  │
│  │  │ Content.js  │  │ Background.js  │  │   Popup UI        │   │  │
│  │  │ • Selections│  │ • Tab tracking │  │ • Toggle on/off   │   │  │
│  │  │ • Copy/Paste│  │ • Event queue  │  │ • View stats      │   │  │
│  │  │ • Page text │  │ • Batch flush  │  │ • Sync now        │   │  │
│  │  └──────┬──────┘  └───────┬────────┘  └───────────────────┘   │  │
│  └─────────┼─────────────────┼───────────────────────────────────┘  │
└────────────┼─────────────────┼──────────────────────────────────────┘
             │  chrome.runtime │
             └────────┬────────┘
                      │ POST /api/events (batch every 30s)
                      ▼
┌──────────────────────────────────────────────────────────────────────┐
│                    Local Backend (Python)                             │
│                                                                      │
│  ┌──────────┐   ┌──────────────┐   ┌──────────────┐                │
│  │ FastAPI   │──▶│ Event        │──▶│ SQLite+FTS5  │                │
│  │ Server    │   │ Processor    │   │ (structured) │                │
│  │ :8420     │   │ dedup+domain │   └──────────────┘                │
│  └──────────┘   └──────┬───────┘                                    │
│       │                │          ┌──────────────┐                   │
│       │                └─────────▶│ ChromaDB     │                   │
│       │                           │ (semantic)   │                   │
│       ▼                           └──────┬───────┘                   │
│  ┌──────────┐                            │                           │
│  │ RAG      │◀───── vector search ───────┘                           │
│  │ Pipeline  │◀───── FTS5 search ────────┘                           │
│  └────┬─────┘                                                        │
│       │                                                              │
│       ▼                                                              │
│  ┌──────────┐                                                        │
│  │ LLM      │  Ollama (local, free) or OpenRouter (cloud)            │
│  └──────────┘                                                        │
└──────────────────────────────────────────────────────────────────────┘
        ▲               ▲               ▲
        │               │               │
   ┌────┴────┐    ┌─────┴─────┐   ┌─────┴─────┐
   │   CLI   │    │ MCP Server│   │ REST API  │
   │ $ brain │    │ Claude/   │   │ curl/apps │
   │  search │    │ VS Code   │   │           │
   └─────────┘    └───────────┘   └───────────┘

🚀 Quick Start

Prerequisites

Python 3.10+
Google Chrome (latest)
Ollama (optional — for AI-powered answers)

1. Clone & Install

git clone https://github.com/ArpitaSethi-12/digital-brain.git
cd digital-brain
pip install -e .

2. Start the Backend

python -m backend.main

Digital Brain backend is ready  🧠
Server running at http://localhost:8420

3. Install the Chrome Extension

Open chrome://extensions/ in Chrome
Enable Developer mode (top-right toggle)
Click Load unpacked → select the extension/ directory
The 🧠 icon appears in your toolbar

4. (Optional) Install Ollama for AI Answers

# Install Ollama from https://ollama.com
ollama serve
ollama pull llama3.2

Without Ollama, Digital Brain still works — it returns retrieved results instead of generated answers.

5. Start Browsing!

Open any website. The extension captures your activity in the background. Then query it:

brain search "python tutorial"
brain ask "What was I reading about yesterday?"
brain stats

💻 CLI Usage

Digital Brain ships with a CLI built on Typer + Rich:

Search

# Basic search
brain search "RAG pipeline"

# Filter by event type
brain search "terminal command" --type copy

# Filter by domain
brain search "react hooks" --domain github.com

# Filter by time window
brain search "python" --last 7d        # last 7 days
brain search "docker" --last 24h       # last 24 hours
brain search "AI paper" --last 2w      # last 2 weeks

Ask (RAG Q&A)

brain ask "What was I working on yesterday related to RAG?"
brain ask "What command did I copy to clear the terminal?" --type copy
brain ask "Which website did I spend the most time on?" --last 7d
brain ask "Summarize what I read about transformers" --no-llm  # skip LLM

Stats & Activity

brain stats                    # top domains + weekly activity
brain stats --period month     # monthly breakdown
brain activity                 # today's timeline
brain activity --date yesterday
brain activity --date 2026-06-01

System

brain status     # backend health + LLM availability
brain reindex    # rebuild vector index from SQLite

🔌 MCP Server

Digital Brain includes an MCP (Model Context Protocol) server that lets AI assistants query your browsing history directly.

How It Works

You:    "What was I working on yesterday related to RAG?"
Claude: → calls search_history("RAG", last="1d")
        → Digital Brain searches local SQLite + ChromaDB
Claude: "Yesterday you visited 3 pages about RAG pipelines..."

Available Tools

Tool	Description
`search_history`	Keyword search with type/domain/time filters
`ask_brain`	RAG-powered natural language Q&A
`get_stats`	Top domains and activity breakdown
`get_activity`	Day's chronological timeline
`get_timeline`	Detailed event feed with full content
`check_status`	Backend health + LLM status

Setup with Claude Desktop

Start the backend: python -m backend.main
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "digital-brain": {
      "command": "python3",
      "args": ["/absolute/path/to/digital-brain/mcp_server.py"]
    }
  }
}

Restart Claude Desktop — the 🧠 tools appear automatically.

Setup with VS Code

Add to .vscode/settings.json:

{
  "mcp": {
    "servers": {
      "digital-brain": {
        "command": "python3",
        "args": ["/absolute/path/to/digital-brain/mcp_server.py"]
      }
    }
  }
}

Test with MCP Inspector

npx -y @modelcontextprotocol/inspector python3 mcp_server.py

📡 API Reference

The backend exposes a REST API at http://localhost:8420:

Method	Endpoint	Description
`GET`	`/api/health`	Backend health status
`POST`	`/api/events`	Ingest event batch from extension
`GET`	`/api/search?q=...`	Full-text search with filters
`POST`	`/api/ask`	RAG question answering
`GET`	`/api/ask?q=...`	RAG via query string
`GET`	`/api/stats/domains`	Top domains by time spent
`GET`	`/api/stats/activity?period=week`	Daily event breakdown
`GET`	`/api/stats/timeline?date=2026-06-01`	Event timeline for a date
`POST`	`/api/index/rebuild`	Rebuild vector index
`GET`	`/api/llm/status`	Check LLM availability

Example: Ask a Question

curl -X POST http://localhost:8420/api/ask \
  -H "Content-Type: application/json" \
  -d '{"question": "What did I copy about clearing the terminal?"}'

Response:

{
  "answer": "You copied the command 'clear && printf ...' from Stack Overflow.",
  "sources": [
    {
      "event_type": "copy",
      "domain": "stackoverflow.com",
      "content": "clear && printf '\\e[3J'"
    }
  ],
  "llm_used": true,
  "retrieval_count": 3
}

Example: Search History

curl "http://localhost:8420/api/search?q=RAG&event_type=page_visit&limit=5"

📁 Project Structure

digital-brain/
├── extension/                  # Chrome Extension (Manifest V3)
│   ├── manifest.json           # Permissions & config
│   ├── background.js           # Service worker — event batching, tab tracking
│   ├── content.js              # Content script — selections, copy/paste, page text
│   ├── popup.html/js/css       # Extension popup UI
│   └── icons/                  # Extension icons
│
├── backend/                    # Python FastAPI Backend
│   ├── main.py                 # App entry point with CORS & lifespan
│   ├── config.py               # Environment-based configuration
│   ├── models.py               # 13 Pydantic models (API contract)
│   ├── database.py             # SQLite + FTS5 (schema, CRUD, search)
│   ├── routers/
│   │   ├── events.py           # POST /api/events
│   │   ├── search.py           # GET /api/search
│   │   ├── stats.py            # GET /api/stats/*
│   │   └── ask.py              # POST /api/ask + index rebuild
│   └── services/
│       ├── event_processor.py  # Validate, dedup, extract domains
│       ├── vector_store.py     # ChromaDB operations
│       ├── rag.py              # RAG pipeline (vector + FTS → LLM)
│       ├── llm.py              # Ollama / OpenRouter client
│       └── indexer.py          # Vector index rebuild
│
├── cli/
│   └── brain.py                # Typer + Rich CLI (6 commands)
│
├── mcp_server.py               # MCP server (6 tools for AI assistants)
│
├── data/                       # Local storage (auto-created, gitignored)
│   ├── brain.db                # SQLite database + FTS5 index
│   └── chroma/                 # ChromaDB vector store
│
├── .env.example                # Environment variable template
├── pyproject.toml              # Project config & dependencies
└── README.md

⚙️ Configuration

Copy the example and customize:

cp .env.example .env

Variable	Default	Description
`BRAIN_HOST`	`127.0.0.1`	Backend host
`BRAIN_PORT`	`8420`	Backend port
`BRAIN_DATA_DIR`	`./data`	Storage directory
`BRAIN_LLM_PROVIDER`	`ollama`	`ollama` or `openrouter`
`OLLAMA_BASE_URL`	`http://localhost:11434`	Ollama server URL
`OLLAMA_MODEL`	`llama3.2`	Ollama model name
`OPENROUTER_API_KEY`	—	OpenRouter API key (optional)
`BRAIN_RAG_TOP_K`	`8`	Number of results for RAG context

🧬 How RAG Works

User: "What command did I copy to clear the terminal?"
 │
 ├──▶ ChromaDB Semantic Search
 │    Finds events with similar meaning
 │    (e.g., "bash clear screen" matches "terminal command")
 │
 ├──▶ SQLite FTS5 Keyword Search
 │    Finds events containing exact words
 │    (e.g., "clear" AND "terminal")
 │
 ├──▶ Merge & Deduplicate
 │    Combines both result sets by event ID
 │
 ├──▶ Format Context Block
 │    Prepares retrieved events as LLM context
 │
 └──▶ LLM Generation (Ollama)
      Generates natural language answer
      grounded in your actual browsing data

Result: "You copied 'clear && printf \\e[3J' from stackoverflow.com on June 8th."

🛡️ Privacy

Digital Brain is privacy-first by design:

✅ All data stored locally in data/ directory
✅ Chrome extension only communicates with localhost:8420
✅ MCP server runs locally via stdio — no network requests
✅ LLM runs locally via Ollama — your data never leaves your machine
✅ No analytics, no telemetry, no cloud sync
⚠️ OpenRouter is optional and only used if you explicitly set OPENROUTER_API_KEY

🛠️ Tech Stack

Layer	Technology
Data Capture	Chrome Extension (Manifest V3)
Backend	Python 3.10+ · FastAPI · Uvicorn
Structured DB	SQLite 3 + FTS5
Vector DB	ChromaDB (all-MiniLM-L6-v2 embeddings)
Local LLM	Ollama (llama3.2)
Cloud LLM	OpenRouter (optional)
CLI	Typer + Rich
MCP	FastMCP (mcp SDK)
Validation	Pydantic v2
HTTP Client	httpx (async)

📊 Project Stats

Metric	Value
Total Lines of Code	~3,800
Python Files	18
JavaScript Files	3
API Endpoints	10
CLI Commands	6
MCP Tools	6
Pydantic Models	13
Event Types Captured	6
Dependencies	10

🗺️ Roadmap

🌐 Web chat UI with streaming responses
📅 Smarter date parsing ("yesterday", "last week") in RAG
🔒 Optional encryption at rest for data/
🔌 MCP Registry listing
📱 Firefox extension
🧠 Multi-turn conversation memory
📦 PyPI package (pip install digital-brain)

🤝 Contributing

Contributions are welcome! Here's how:

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

📄 License

This project is licensed under the MIT License — see the LICENSE file for details.

Available Tools

6 tools

ask_brainA

Ask a natural-language question about the user's browsing history.

Uses RAG (Retrieval-Augmented Generation) to find relevant browsing events and generate an AI-powered answer. Requires Ollama or OpenRouter.

Args: question: Natural language question (e.g. "What was I working on yesterday related to RAG?") event_type: Filter by type: page_visit, selection, copy, paste, focus_time, page_content domain: Filter by website domain last: Time window (e.g. "7d", "24h", "2w")

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes
`event_type`	No
`domain`	No
`last`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses use of RAG and requirement of Ollama/OpenRouter, which is helpful. However, it omits details on response behavior, error handling, or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with purpose, then details. Every sentence adds value without redundancy. The Args list is structured and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema (not shown) so return values need not be described. The description covers input semantics, technology, and requirements. It is complete for basic use, though a note on answer format or limitations would improve it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description's Args section adds meaning: examples for question, allowed values for event_type, domain description, and format for last. This compensates well, though further detail on defaults could elevate it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it answers natural-language questions about browsing history using RAG. It distinguishes from siblings like search_history by emphasizing natural language and AI-powered answers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for natural language queries but does not explicitly contrast with sibling tools or state when not to use it. No exclusions or alternatives are provided, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_statusA

Check the health status of the Digital Brain backend and LLM.

Reports backend status, database size, event counts, vector index size, and whether an LLM (Ollama/OpenRouter) is available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It discloses what is reported but does not mention any behavioral traits like side effects, auth needs, or rate limits. Basic but adequate for a read-only health check.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded purpose, no redundancy. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 0 params and an output schema, the description fully conveys what the tool does and what it returns. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. Description does not need to add param info, but it lists reported items which adds value. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks health status of backend and LLM, listing specific reports. It is distinct from siblings like get_stats or get_timeline which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the purpose is clear, no explicit guidance is given on when to use this vs alternatives. Context implies it's for monitoring, but lacks explicit when-to-use or when-not-to-use instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_activityA

View a chronological timeline of browsing activity for a specific day.

Args: date: Date to view — "today", "yesterday", or "YYYY-MM-DD" format

ParametersJSON Schema

Name	Required	Description	Default
`date`	No		today

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It implies a read-only operation ('View') and mentions chronological order, but lacks details on authentication, rate limits, or whether results are paginated. It does not contradict annotations (none exist).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences with no redundancy. The first sentence states the purpose, the second explains the parameter. It is front-loaded and every word is informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, output schema exists), the description is largely complete. It covers what the tool does and how to use the parameter. However, it could briefly mention what data is returned (e.g., URLs or summaries) to fully set expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It adds valuable meaning for the only parameter 'date' by specifying allowed values ('today', 'yesterday', 'YYYY-MM-DD'), which goes beyond the schema's type and default. However, it could clarify time zone or format strictness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'View a chronological timeline of browsing activity for a specific day.' It specifies the resource (browsing activity), verb (view), and scope (chronological timeline, specific day), effectively distinguishing it from sibling tools like search_history or get_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides basic context (for a specific day and accepted date formats) but does not explicitly state when to use this tool versus alternatives like get_timeline or search_history. No 'when not to use' guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_statsA

Get browsing activity statistics — top domains and daily breakdown.

Args: period: Time period for activity breakdown: "day", "week", or "month"

ParametersJSON Schema

Name	Required	Description	Default
`period`	No		week

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must cover behavioral traits. Only states it returns aggregated statistics (top domains, daily breakdown) and period parameter. No mention of authentication, rate limits, data freshness, or whether it mutates state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: two sentences plus argument documentation. Front-loads main purpose. Could benefit from slightly more structure or a brief usage note, but efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, return values need not be documented. However, lacks contextual info like data time range, source scope, or limitations. Acceptable for a simple stats tool but could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, description adds critical meaning: lists valid values for 'period' (day, week, month) and explains its purpose. Schema only had type string with default 'week', so description provides essential usage info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'browsing activity statistics — top domains and daily breakdown', specifically identifying verb and resource. Differentiates from siblings like get_activity and get_timeline which likely deal with raw data or timelines.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs siblings (e.g., get_activity, search_history). Does not provide when-not or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_timelineA

Get a detailed chronological event feed for a specific date.

Similar to get_activity but returns more detail per event including full content previews. Useful for reconstructing what happened on a day.

Args: date: Date — "today", "yesterday", or "YYYY-MM-DD" limit: Maximum events to return (default 20)

ParametersJSON Schema

Name	Required	Description	Default
`date`	No		today
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must convey behavioral traits. It states that the tool returns a 'detailed chronological event feed' with 'full content previews,' implying a read-only operation with no side effects. No contradictions with annotations (none present).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear purpose sentence, a comparison with a sibling tool, a use-case statement, and a parameter list. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description need not explain return values. It adequately covers purpose, usage context, parameter semantics, and comparison with a sibling tool. No gaps remain for an agent to misuse this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides an explicit Args section that explains both parameters beyond what the schema offers. It specifies valid values for 'date' ('today', 'yesterday', or 'YYYY-MM-DD') and explains 'limit' as 'Maximum events to return (default 20).' This is essential given 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get a detailed chronological event feed for a specific date.' It distinguishes itself from the sibling tool get_activity by noting that it returns more detail per event, including full content previews.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use this tool ('useful for reconstructing what happened on a day') and compares it to get_activity. However, it does not explicitly state when not to use this tool or suggest alternative tools for different scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_historyA

Search the user's Chrome browsing history by keyword.

Searches through page visits, text selections, copy/paste events, and page content. Returns matching results with context.

Args: query: Search term (e.g. "RAG pipeline", "terminal command") event_type: Filter by type: page_visit, selection, copy, paste, focus_time, page_content domain: Filter by website domain (e.g. "github.com") last: Time window (e.g. "7d" for 7 days, "24h" for 24 hours, "2w" for 2 weeks) limit: Maximum number of results (default 10)

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`event_type`	No
`domain`	No
`last`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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 describes the tool's capabilities but fails to disclose important behavioral traits like accessing personal data (user's browsing history) and potential privacy implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections and examples, but it is verbose. Some sentences could be merged or removed without losing clarity. It earns its place but could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, 1 required) and no annotations, the description covers purpose, parameters, and examples well. It lacks usage guidelines and behavioral context, but overall it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description excellently compensates by explaining each parameter with examples (e.g., 'RAG pipeline' for query) and clarifying defaults (limit=10). It adds significant value beyond the schema's type constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches Chrome browsing history by keyword, listing the event types it covers (page visits, selections, etc.). Sibling tools have distinct purposes (ask_brain, check_status, etc.), so this tool is well-distinguished.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool vs alternatives. It is implied by the unique functionality (searching history), but no guidance on when not to use it or prerequisites is given.

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.

6 tool updatesv0.1.0Jun 18, 2026
- First observedask_brain
- First observedcheck_status
- First observedget_activity
- First observedget_stats
- First observedget_timeline
- First observedsearch_history

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored 2026-06-18 07:45 across 6 tools

Disambiguation4/5

Most tools are distinct, but get_activity and get_timeline have overlapping purposes (both show timeline, get_timeline just more detailed). Also, ask_brain and search_history both retrieve history but through different interfaces (Q&A vs keyword search), which could cause ambiguity. Overall, boundaries are clear for most tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: ask_brain, check_status, get_activity, get_stats, get_timeline, search_history. The pattern is uniform and predictable.

Tool Count5/5

With 6 tools, the set is well-scoped for a browsing history assistant. Each tool serves a distinct need (Q&A, health check, daily overview, statistics, detailed timeline, keyword search) without redundancy or bloat.

Completeness4/5

The tool surface covers the main browsing history interactions: query, search, timeline, stats, health. However, there is no dedicated tool to retrieve all events of a specific type without a date or search query, which is a minor gap. Otherwise, the set feels complete for a read-only assistant.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AmberOAuth
com.ambermem
Long-term memory for AI assistants. Hybrid retrieval, query expansion, auto-topics.
Knowledge & Memory RAG Systems Vector Databases
21
Ragora A
io.github.mregmi
Search your knowledge bases from any AI assistant using hybrid RAG.
RAG Systems Search Knowledge & Memory
2
OneAIMemoryOAuth
io.github.AmxnCode
Cross-device AI memory with encrypted activity capture and context handoff between AI tools
Knowledge & Memory RAG Systems Autonomous Agents
1
TrafficBud SEO
io.trafficbud
Real SEO data for AI assistants: page audits, Keyword Planner volumes, Search Console history.
Marketing Search
1

Related MCP Servers

Search History MCP Server
Search OS Automation Developer Tools
ronantakizawa
F
license
A
quality
D
maintenance
Enables access to and searching of browser history from major browsers (Brave, Chrome, Firefox, Safari, Edge, Arc, Opera, DuckDuckGo) to personalize LLM interactions and retrieve past browsing data through natural language queries.
Updated 10 months ago (2025-10-28 04:30 UTC)
3
9
-
Chrome History & Bookmarks MCP
Browser Automation Search File Systems
ananddharne
F
license
Not graded
quality
D
maintenance
Enables AI assistants to search and analyze Chrome browser history and bookmarks data locally, including keyword searches, date range filtering, recent browsing activity, and usage statistics across all platforms.
Updated a year ago (2025-08-18 01:59 UTC)
2
-
blackmount-mcpofficial
Search Browser Automation
BlackMount-ai
A
license
Not graded
quality
A
maintenance
Enables AI assistants to access and search local browser history, bookmarks, open tabs, and downloads for personalized context.
Updated 4 months ago (2026-05-27 06:58 UTC)
MIT
MyChatArchive MCP Server
Search Knowledge & Memory
1ch1n
A
license
Not graded
quality
A
maintenance
Enables semantic search across your local AI conversation history (ChatGPT, Claude, etc.) and provides tools to retrieve context, capture thoughts, and get profile summaries.
Updated a month ago (2026-08-05 03:51 UTC)
65
AGPL 3.0

✨ Features

📐 Architecture

🚀 Quick Start

Prerequisites

1. Clone & Install

2. Start the Backend

3. Install the Chrome Extension

4. (Optional) Install Ollama for AI Answers

5. Start Browsing!

💻 CLI Usage

Search

Ask (RAG Q&A)

Stats & Activity

System

🔌 MCP Server

How It Works

Available Tools

Setup with Claude Desktop

Setup with VS Code

Test with MCP Inspector

📡 API Reference

Example: Ask a Question

Example: Search History

📁 Project Structure

⚙️ Configuration

🧬 How RAG Works

🛡️ Privacy

🛠️ Tech Stack

📊 Project Stats

🗺️ Roadmap

🤝 Contributing

📄 License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

blackmount-mcpofficial