Integrates with VS Code Copilot to provide access to project context such as documentation and architecture decisions.
Supports JetBrains IDEs through the Continue extension, giving the assistant access to project context.
Uses Ollama as the embedding model provider for semantic search over project documentation.
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-project-context-server find documentation about authentication flow"
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 Project Context Server provides a robust, production-ready Model Context Protocol (MCP) server implementation designed to give Large Language Models (LLMs) persistent, searchable access to your project's contextual information.
🔍 Semantic Search Engine: Query your project documentation using natural language
📚 Persistent Knowledge Base: Store and retrieve information from .context/ directory structure
🏗️ Modular Architecture: Clean 4-layer design following SOLID principles
🎯 ADR Integration: Full support for Architecture Decision Records with lifecycle management
📝 Session Tracking: Record and retrieve session notes for future reference
💾 Vector Store Backend: ChromaDB for fast, persistent, embedded vector storage
🔄 Easy Reindexing: Rebuild your knowledge base with a single command
✅ Model-Agnostic: Works with any LLM model via Ollama (Other providers coming)
✅ Configuration-Free: Environment variable-based setup, no hardcoded paths
✅ Cross-Platform: POSIX path normalization ensures consistency across OS
✅ Async-First: All operations use async/await for performance and scalability
✅ Error-Resilient: Graceful error handling with informative messaging
Related MCP server: context-hub-mcp
Before installing, ensure you have:
Python 3.11+ installed
Ollama running with an embedding model (e.g., nomic-embed-text)
At least 2GB RAM available
4.5GB disk space for ChromaDB (minimum)
pip install mcp-project-context-servergit clone https://github.com/your-org/mcp-project-context-server.git
cd mcp-project-context-server
pip install -e ".[dev]" # Install with development dependenciesSet the following environment variables:
# Ollama Configuration (Required)
export OLLAMA_HOST="http://localhost:11434"
export EMBED_MODEL="nomic-embed-text"
# ChromaDB Configuration (Optional)
export CHROMA_DIR="$HOME/.mcp-data/chroma"
# Runtime Configuration
export EMBED_CONCURRENCY="4" # Max concurrent embeddings
export PROJECT_PATH="/path/to/project" # Optional, defaults to CWDThe server follows the standard MCP protocol, making it compatible with any MCP client that supports stdio transport.
Client | Status | Setup Instructions |
Claude Desktop | ✅ Tested | |
Claude Code | ✅ Tested | |
Cursor | ✅ Tested | See Cursor Setup |
Continue | ✅ Tested | See Continue Setup |
Windsurf | ✅ Compatible | See Windsurf Setup |
VS Code Copilot | ✅ Compatible |
Install the server (see Installation)
Locate the config file for your OS:
OS | Config File Location |
Windows |
|
macOS |
|
Linux |
|
Configure MCP settings in claude_desktop_config.json:
Windows:
{
"mcpServers": {
"project-context": {
"command": "python",
"args": ["-m", "mcp_project_context_server"],
"env": {
"OLLAMA_HOST": "http://localhost:11434",
"EMBED_MODEL": "nomic-embed-text",
"CHROMA_DIR": "%USERPROFILE%\\.mcp-data\\chroma"
}
}
}
}macOS / Linux:
{
"mcpServers": {
"project-context": {
"command": "python",
"args": ["-m", "mcp_project_context_server"],
"env": {
"OLLAMA_HOST": "http://localhost:11434",
"EMBED_MODEL": "nomic-embed-text",
"CHROMA_DIR": "~/.mcp-data/chroma"
}
}
}
}Verify the server is connected:
claude mcp listUse in Claude Code by referencing the tools directly in your session, or asking questions about your project context.
Try asking: "What was the decision in ADR-00001?"
Verify semantic search works with project-specific queries
Install the server (see Installation)
Add the MCP server using one of two methods:
Option A — CLI (Recommended):
claude mcp add project-context python -- -m mcp_project_context_serverTo include environment variables:
claude mcp add project-context \
-e OLLAMA_HOST=http://localhost:11434 \
-e EMBED_MODEL=nomic-embed-text \
-e CHROMA_DIR=~/.mcp-data/chroma \
-- python -m mcp_project_context_serverOption B — Config file:
Claude Code supports both user-level and project-level configuration:
Scope | Location |
User (global) |
|
Project |
|
Add the following to the mcpServers key:
{
"mcpServers": {
"project-context": {
"command": "python",
"args": ["-m", "mcp_project_context_server"],
"env": {
"OLLAMA_HOST": "http://localhost:11434",
"EMBED_MODEL": "nomic-embed-text",
"CHROMA_DIR": "~/.mcp-data/chroma"
}
}
}
}Verify the server is connected:
Use in Claude Code by referencing the tools directly in your session, or asking questions about your project context.
Install the MCP server (see Installation)
Choose a config scope — Cursor supports both global and project-level MCP configuration:
Scope | Windows | macOS / Linux |
Global |
|
|
Project |
|
|
Configure in mcp.json:
{
"mcpServers": {
"project-context": {
"command": "python",
"args": [
"-m",
"mcp_project_context_server"
],
"env": {
"OLLAMA_HOST": "http://localhost:11434",
"EMBED_MODEL": "nomic-embed-text",
"CHROMA_DIR": "~/.mcp-data/chroma"
}
}
}
}Test functionality:
Use @project-context in chat
Ask context-aware questions about your project
Access ADRs and documentation via natural language
Install the Continue VS Code or JetBrains extension
Locate the config file for your OS:
OS | Config File Location |
Windows |
|
macOS / Linux |
|
Continue also supports
config.jsonfor legacy setups, butconfig.yamlis the current default.
Add to config.yaml:
mcpServers:
- name: project-context
command: python
args:
- "-m"
- mcp_project_context_server
env:
OLLAMA_HOST: "http://localhost:11434"
EMBED_MODEL: "nomic-embed-text"
CHROMA_DIR: "~/.mcp-data/chroma"Or if using config.json:
{
"mcpServers": [
{
"name": "project-context",
"command": "python",
"args": ["-m", "mcp_project_context_server"],
"env": {
"OLLAMA_HOST": "http://localhost:11434",
"EMBED_MODEL": "nomic-embed-text",
"CHROMA_DIR": "~/.mcp-data/chroma"
}
}
]
}Usage:
Trigger context queries in the chat panel
Access project documentation mid-conversation
Maintain context across multi-turn conversations
Install MCP server via terminal or package manager
Locate the MCP config file for your OS:
OS | Config File Location |
Windows |
|
macOS / Linux |
|
Configure in mcp_config.json (create if not exists):
{
"mcpServers": {
"project-context": {
"command": "python",
"args": ["-m", "mcp_project_context_server"],
"env": {
"OLLAMA_HOST": "http://localhost:11434",
"EMBED_MODEL": "nomic-embed-text",
"CHROMA_DIR": "~/.mcp-data/chroma"
}
}
}
}Restart Windsurf and verify the MCP server appears under Settings → MCP Servers.
MCP support is built into VS Code via GitHub Copilot (no separate extension required). Requires VS Code 1.99+ with the Copilot extension.
Install the server (see Installation)
Choose a config scope:
Option A — Workspace (.vscode/mcp.json):
Create .vscode/mcp.json in your project root (works identically on all OSes):
{
"servers": {
"project-context": {
"type": "stdio",
"command": "python",
"args": ["-m", "mcp_project_context_server"],
"env": {
"OLLAMA_HOST": "http://localhost:11434",
"EMBED_MODEL": "nomic-embed-text",
"CHROMA_DIR": "${env:USERPROFILE}/.mcp-data/chroma"
}
}
}
}Note: Use
${env:USERPROFILE}/.mcp-data/chromaon Windows or~/.mcp-data/chromaon macOS/Linux forCHROMA_DIR.
Option B — User settings (settings.json):
Open VS Code settings (Ctrl + , / Cmd + ,) and add to settings.json:
{
"mcp": {
"servers": {
"project-context": {
"type": "stdio",
"command": "python",
"args": ["-m", "mcp_project_context_server"],
"env": {
"OLLAMA_HOST": "http://localhost:11434",
"EMBED_MODEL": "nomic-embed-text",
"CHROMA_DIR": "~/.mcp-data/chroma"
}
}
}
}
}Use in Copilot Chat by switching to Agent mode and the MCP tools will be available automatically.
While PyCharm doesn't natively support MCP, you can:
Use the CLI mode:
Windows (PowerShell):
project-context-server search "your query"macOS / Linux:
project-context-server search "your query"Or use the Python interpreter:
from mcp_project_context_server.server import run
run() # Start server, then connect via MCP client-- In your Neovim config (works on Windows, macOS, and Linux)
require('mcp').connect({
name = 'project-context',
command = 'python',
args = {'-m', 'mcp_project_context_server'},
env = {
OLLAMA_HOST = 'http://localhost:11434'
}
})Similar to VS Code, configure in Sublime's MCP settings file with the same JSON structure.
Ask natural language questions about your project:
# Example: Ask about your project's architecture
# Expected: Retrieves relevant ADRs and documentation
search_project_context(
query="How do we handle data persistence?",
n_results=5
)Get all documentation at once:
load_project_context()
# Returns concatenated content of:
# - project.md
# - All ADRs
# - Latest session filesave_session_summary(
summary="Investigated chunking strategy alternatives, decided on fixed-size for now"
)
# Creates: .context/sessions/YYYY-MM-DD.mdindex_project_context()
# Drops existing collection and rebuilds from .context/mcp-project-context-server/
├── src/mcp_project_context_server/
│ ├── __init__.py
│ ├── __main__.py
│ ├── server.py # MCP server entry point
│ ├── tools/
│ │ ├── load_context.py # load_project_context tool
│ │ ├── search_context.py # search_project_context tool
│ │ ├── save_session.py # save_session_summary tool
│ │ └── index_context.py # index_project_context tool
│ ├── integrations/
│ │ ├── chroma/
│ │ │ └── client.py # ChromaDB client
│ │ └── ollama/
│ │ └── client.py # Ollama client
│ ├── indexing/
│ │ ├── chroma/
│ │ │ └── indexer.py # Chunking & embedding pipeline
│ │ └── ollama/
│ │ └── embedder.py # Embedding wrappers
│ └── helpers/
│ └── context.py # Utility functions
├── .context/ # Project context directory
│ ├── project.md # Project overview
│ ├── sessions/ # Session notes
│ └── decisions/ # ADRs
├── scripts/
│ └── test_client.py # Integration smoke test
├── README.md
├── pyproject.toml
└── LICENSEpython scripts/test_client.py# Install
# Install testing dependencies
python -m pip install testsuite
# Run pytest
pytest tests/
# Test coverage
pytest --cov=src/mcp_project_context_server
# Lint and format
ruff check src/
black src/Variable | Default | Description |
|
| Ollama server URL |
|
| Embedding model name |
|
| ChromaDB persistence directory |
|
| Max concurrent embedding requests |
| CWD | Path to project root (optional) |
|
| Prefix for tool names |
Auto-reindex: Watchdog-based file monitoring for automatic reindexing
Codebase Indexing: Repomix integration for source code analysis
Enhanced ADR Tools: First-class MCP tools for ADR lifecycle
Repository Bootstrapping: Automatic .context/ generation
Batch Operations: Bulk ADR updates and session imports
Contributions are welcome! See CONTRIBUTING.md for detailed contribution guidelines.
Fork the repository
Create a feature branch
Commit your changes
Push to the branch
Open a Pull Request
This project is licensed under the GNU AFFERO GENERAL PUBLIC LICENSE Version 3 - see the LICENSE file for details.
MCP Team: For the Model Context Protocol
ChromaDB: For the vector store implementation
Ollama: For the embedding model hosting
Built with ❤️ for better LLM project understanding
Re-index the .context/ directory into the vector store. Run this after updating project.md, adding ADRs, or refreshing BUNDLE.md.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'Re-index...' without explaining whether the operation is destructive, whether it overwrites existing data, or what the impact is on the vector store. This is a significant gap for a mutation tool.
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 two-sentence paragraph that is concise and front-loaded. The first sentence states the action, the second gives usage triggers. No unnecessary words, and each sentence earns its place.
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 (one param, no output schema, no annotations), the description covers the basic purpose and usage triggers. However, it lacks details about the parameter and the effect on the vector store, making it minimally viable but not fully 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?
The only parameter is project_path, and the schema description coverage is 0%. The description does not mention project_path or provide any additional meaning beyond its name. It relies on the parameter name being self-explanatory, but adds no context about format or restrictions.
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 action: 'Re-index the .context/ directory into the vector store.' It also provides context on when to run it, which helps understand its purpose. However, it does not explicitly distinguish from siblings like search_project_context, but the unique action 're-index' sets it apart.
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 gives clear triggers for use: 'after updating project.md, adding ADRs, or refreshing BUNDLE.md.' This provides good guidance on when to use the tool. It lacks explicit when-not-to-use instructions or alternatives, but the given context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List repositories accessible via the configured repository provider. In multi-tenant deployments, use this to discover which repositories are available before calling other tools. Optionally filter by organisation name.
| Name | Required | Description | Default |
|---|---|---|---|
| org | No | Optional: filter results to repositories in this organisation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only adds 'accessible via configured provider', but does not disclose pagination, rate limits, auth needs, or behavior when provider is unavailable.
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?
Two sentences, compact and front-loaded. No unnecessary words; every sentence adds value.
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?
No output schema, and description omits return format, pagination, ordering, or error handling. For a simple list tool, it is borderline adequate but lacks 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% and parameter description in schema is clear. Description repeats essentially the same info, adding no new semantics beyond the schema.
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?
Description clearly states the action (list) and resource (repositories), and distinguishes from sibling tools which focus on project context and sessions.
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 advises using this tool for discovery in multi-tenant deployments before other tools, and mentions optional filtering. Lacks when-not-to-use or alternatives, but siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load the full project context for the given project path. Returns project.md, all ADRs, and the latest session summary. You MUST call this at the start of every session.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Absolute filesystem path, a short 'owner/repo' identifier, or a full https:// repository URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It describes what is returned but omits behavioral traits such as read-only guarantee, error handling, or side effects. The added context of what files are loaded is useful but incomplete.
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?
Two sentences: the first states purpose, the second adds mandatory usage. Every word earns its place; no fluff.
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 (one parameter, no output schema), the description adequately covers purpose and usage. Minor omissions like read-only or error handling are acceptable for a loader tool with strong usage guidelines.
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 a single parameter (project_path) already described in the schema. The description adds 'for the given project path' which does not provide additional meaning beyond the schema, meeting the baseline.
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 specifies the verb 'Load' and the resource 'full project context' for a given project path. It lists the specific items returned (project.md, ADRs, session summary) and is distinct from sibling tools like index_project_context or search_project_context.
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 states 'You MUST call this at the start of every session,' providing a clear directive on when to use the tool. No exclusion of alternatives is needed as this is the primary loading tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a summary of the current session to .context/sessions/YYYY-MM-DD.md. Call this at the end of a session with a concise summary of what was done.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | Markdown summary: what was worked on, decisions made, next steps. | |
| project_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the output location and naming convention but does not disclose overwrite behavior, directory creation, or any side effects. Basic but adequate for a simple 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?
Two concise sentences front-load the key information: purpose, destination, and usage timing. No unnecessary words or repetition.
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 simple parameters and no output schema or annotations, the description covers the essential aspects. It could mention whether the file is created/overwritten, but the overall completeness is high for the tool's complexity.
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 50%. The description adds meaning to 'summary' by listing what to include (work done, decisions, next steps). However, 'project_path' remains unexplained beyond its type, missing an opportunity to clarify its format or constraints.
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 saves a session summary to a specific file path, distinguishing it from sibling tools that index, load, or search project context.
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 says to call at end of session with a concise summary, providing clear when-to-use guidance. Does not discuss alternatives or when not to use, but the context with sibling tools implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantically search the indexed project context. Use this to find relevant past decisions, architecture notes, or code summaries related to your current task.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query | |
| n_results | No | ||
| project_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'semantically search' without specifying side effects, permissions, or prerequisites like whether the context must be indexed first. Minimal behavioral insight.
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, concise and front-loaded with the core purpose. No unnecessary words, though slightly more structured parameter hints could improve clarity.
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 three parameters, no output schema, and no annotations, the description is too sparse. It omits details about the required project_path format, result behavior, and any prerequisites, leaving significant gaps for correct usage.
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 low (33%). The description adds context for the query parameter via examples, but does not explain the required 'project_path' parameter or 'n_results' (default but no description). The description does not compensate for the low schema coverage.
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 states a specific verb (search) and resource (indexed project context), and gives concrete examples of what to find (past decisions, architecture notes, code summaries). It clearly distinguishes from siblings like index_project_context or list_repositories.
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 when to use the tool ('find relevant past decisions...') but does not explicitly state when not to use it or mention alternatives among sibling tools. Usage guidance is implied but not explicit.
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.
v0.1.0index_project_contextlist_repositoriesload_project_contextsave_session_summarysearch_project_contextEach tool has a distinct purpose: indexing, listing repositories, loading context, saving session summaries, and searching. No overlapping functionality.
All tools follow a consistent verb_noun pattern with snake_case, e.g., index_project_context, load_project_context, save_session_summary.
With 5 tools, the set is well-scoped for a project context server, covering essential operations without bloat.
The tools cover indexing, loading, searching, saving sessions, and listing repositories. Minor gaps like explicit ADR editing are missing, but all core workflows exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cloud-hosted MCP server for durable AI memory
An MCP server that gives your AI access to the source code and docs of all public github repos
Persistent memory for AI agents — log and recall conversation context over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DarkMatterProductions/mcp-project-context-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
