mcp-context
Click on "Install 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., "@mcp-contextsearch for recent error logs"
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.
mcp-context
Keep MCP tool output out of context. Search it instead.
A Claude Code plugin that intercepts large MCP tool outputs via a PostToolUse hook, indexes them into a local FTS5 knowledge base, and replaces the context-window payload with a ~200-byte summary. The full content stays searchable on demand.
This plugin does not make network calls, move credentials, nor execute commands — minimal security exposure.
How It Works
MCP tool returns 47 KB OpenAPI spec
│
▼
┌──────────────────┐
│ PostToolUse │──► Below 5 KB? → pass through unchanged
│ Hook │
│ (posttooluse. │──► Above 5 KB? ─┐
│ mjs) │ │
└──────────────────┘ │
▼
┌────────────────────┐
│ ContentStore │
│ (SQLite FTS5) │
│ │
│ 1. Detect type │
│ 2. Chunk content │
│ 3. Index chunks │
│ 4. Extract vocab │
└────────┬───────────┘
│
▼
Context receives:
~200 B summary +
"call search() to
retrieve details"
│
▼
┌────────────────────┐
│ MCP Server │
│ search · index · │
│ stats │
│ │
│ Returns snippets │
│ around matches │
└────────────────────┘Related MCP server: conversation-search
Install
From the Marketplace (recommended)
/plugin marketplace add byliu-labs/mcp-context
/plugin install mcp-context@mcp-contextRestart Claude Code after installing.
From a Local Clone
git clone https://github.com/byliu-labs/mcp-context.git
cd mcp-context
npm install && npm run build
claude plugin:install .Manual MCP Server Only
Add to your Claude Code MCP config (hook not included):
{
"mcpServers": {
"mcp-context": {
"command": "node",
"args": ["/path/to/mcp-context/build/server.js"]
}
}
}The Problem
MCP tools return large outputs — accessibility snapshots, API responses, test results, documentation. Every byte enters the context window and counts against the token limit.
A single Playwright snapshot is 26 KB. An OpenAPI spec is 47 KB. A page of server logs is 60 KB. In a session with 20+ tool calls, you burn through context fast.
Architecture
Three components, one SQLite database:
PostToolUse Hook (hooks/posttooluse.mjs) — Intercepts MCP tool output after execution.
If output exceeds the byte threshold (default 5 KB), indexes it and replaces it with a summary.
Only intercepts mcp__ prefixed tools; built-in tools (Bash, Read, Grep) pass through.
ContentStore (src/store.ts) — FTS5 knowledge base with content-aware chunking and
multi-layer search. Shared between hook and server via a deterministic DB path
(/tmp/output-indexer-{pid}.db). SQLite WAL mode handles concurrent access.
MCP Server (src/server.ts) — Exposes search, index, and stats tools.
The LLM calls search() to retrieve specific content on demand instead of having
the full output in context.
Chunking Strategies
Content is detected and chunked by type:
Type | Strategy | Example |
JSON | Split by top-level keys, recurse if value > 5 KB | API responses, configs |
Stack trace | Keep error + trace as single unit | Node.js, Python, Go panics |
Markdown | Split by headings with breadcrumb hierarchy | Documentation, READMEs |
Plain text | 50-line groups with 5-line overlap | Logs, test output |
Search
Three-layer fallback ensures matches even with typos:
Porter stemming — FTS5 with
porter unicode61tokenizer. Handles plurals, tenses.Trigram substring — Matches partial words and identifiers like
handleClick.Levenshtein fuzzy — Corrects misspellings (edit distance 1-3 based on word length), then re-searches via layers 1-2.
Results return 300-character snippet windows around match positions (using FTS5 highlight()
markers), not full chunks — so even search results are compact.
Throttling — Search is rate-limited to prevent the LLM from dumping all indexed content back into context. After 5 calls in a 2-minute window, results are reduced to 1 per query. After 10 calls, search is blocked until the window resets.
The Numbers
Real benchmarks from npm run benchmark — generates realistic data, indexes via ContentStore,
measures original bytes vs summary + search results:
Scenario | Original | Summary | Search (top 3) | Context used | Saved |
Playwright snapshot | 26.0 KB | ~200 B | 6.1 KB | 6.3 KB | 76% |
GitHub API (issues) | 16.2 KB | ~200 B | 4.1 KB | 4.3 KB | 73% |
Jest test output | 9.7 KB | ~200 B | 4.4 KB | 4.6 KB | 53% |
OpenAPI spec | 47.1 KB | ~200 B | 1.6 KB | 1.8 KB | 96% |
Node.js stack trace | 2.8 KB | ~200 B | 1.6 KB | 1.8 KB | 37% |
Markdown docs | 3.6 KB | ~200 B | 868 B | 1.0 KB | 71% |
Server access log | 60.2 KB | ~200 B | 18.1 KB | 18.2 KB | 70% |
Summary = hook replacement message (~200 B). Search = top 3 results via searchWithFallback.
Outputs below the 5 KB threshold pass through unchanged — no overhead for small results.
Tools
search
Search indexed content with multi-layer fallback.
search({ queries: ["error database connection", "retry logic"], source: "stack-trace-1", limit: 3 })Batch all queries in one call (array)
Use
sourceto scope results to a specific indexed outputReturns snippet windows, not full chunks
index
Manually index content into the knowledge base.
index({ content: "...", source: "my-docs" })Useful for indexing content that didn't come through the hook (e.g., file contents, clipboard data).
stats
Session statistics: bytes indexed, bytes returned to context, savings ratio, per-tool breakdown.
Configuration
Variable | Default | Description |
|
| Byte threshold for indexing (outputs below this pass through) |
Set via environment variable:
OUTPUT_INDEXER_THRESHOLD=10240 claudeThe SQLite database is created at /tmp/output-indexer-{pid}.db and cleaned up on exit.
Stale databases from crashed sessions are garbage-collected on startup (>24h old or dead PID).
Requirements
Node.js 18+
Claude Code CLI
Contributing
See CONTRIBUTING.md for development setup, testing, and PR guidelines.
License
Acknowledgments
Search patterns and FTS5 architecture inspired by mksglu/claude-context-mode (MIT).
Available Tools
1 toolindexIndex ContentA
Index content into the searchable knowledge base.
Use for storing documentation, API references, or any content you want to search later. After indexing, use search() to retrieve specific sections on-demand.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Label for the indexed content (e.g., 'react-docs', 'api-reference') | |
| content | Yes | The text content to index (max 10MB) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for transparency. It states the tool indexes content but omits details on idempotency, overwrite behavior, or potential side effects, which are important for a write operation.
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 two clear sentences: the first declares purpose, the second provides usage guidance. No extraneous text.
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 simple with two parameters and no output schema. The description covers purpose and usage adequately. Minor gap: no mention of return value or error handling, but not critical for a basic indexing tool.
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 100%, so the baseline is 3. The description does not add extra parameter semantics beyond the schema's own descriptions, but the schema has adequate explanations for 'source' and 'content'.
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's action ('index content') and resource ('searchable knowledge base'). It is specific and actionable.
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 explicitly recommends when to use the tool (storing documentation, API references, etc.) and directs users to the sibling tool 'search()' for retrieval, providing clear usage guidance.
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. Dates show when Glama detected each change.
1 tool update
v0.1.0- First observed
index
TDQS
Only one tool exists, so there is no possibility of confusion between tools.
With a single tool, naming consistency is automatically maintained.
The server claims to support both indexing and searching, but only provides an index tool, making the count insufficient for its stated purpose.
The server describes a search capability that is not implemented, leaving a critical gap and making the tool set severely incomplete.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Hosted MCP memory: save sessions/decisions once, search from Claude, Cursor, ChatGPT. EU-hosted FTS.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Persistent memory for AI agents — log and recall conversation context over MCP.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenancePersistent memory MCP server for AI coding agents. Stores, searches, and retrieves context across sessions using SQLite and FTS5.-
- FlicenseNot gradedqualityDmaintenanceFull-text search over Claude Code conversation history using SQLite FTS5, exposing indexed transcripts as MCP tools for searching, browsing, and reading turns.3-
- FlicenseAqualityBmaintenanceA local-first document retrieval engine that mounts as an MCP tool for agents to index files, search for relevant passages, and let the agent's own LLM answer.4-
- FlicenseNot gradedqualityCmaintenanceEnables AI assistants to fetch webpages, convert them to Markdown, index into SQLite FTS5, and query the knowledge base through MCP tools.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/byliu-labs/mcp-context'
If you have feedback or need assistance with the MCP directory API, please join our Discord server