Context Portal MCP
Context Portal (ConPort) keeps a project's decisions, tasks and patterns in SQLite with semantic search and serves them to the agent over MCP via stdio
- 768 ★ on the repository
- Last commit
- Apache-2.0
Extended access
Why this level
- Writes and deletes records in the workspace's local SQLite database and vector store, with tools that delete decisions, tasks and data
- The export and import tools read and write Markdown files at a path the agent passes
- The database folder is chosen by `workspace_id` from the agent's call or by auto-detection walking up from the current folder
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add mcp/context-portalDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- Writes and deletes records in the workspace's local SQLite database and vector store, with tools that delete decisions, tasks and data
- The export and import tools read and write Markdown files at a path the agent passes
- The database folder is chosen by `workspace_id` from the agent's call or by auto-detection walking up from the current folder
This is third-party code. Review the repository files before installing.
What it does
Context Portal, or ConPort, is a Python MCP server that maintains a project memory bank for each workspace. A SQLite database is created automatically in a `context_portal/` folder, with a ChromaDB vector store beside it. The agent writes decisions with their rationale, task statuses, architecture patterns and free-form data such as a glossary, and later retrieves them by full-text and semantic search. Vectors are built by the local `all-MiniLM-L6-v2` model from the `sentence-transformers` package. Records are linked with the `link_conport_items` tool, and the links form a project knowledge graph. Product context and the current working context are stored with version history, and `get_item_history` returns earlier states. `get_recent_activity_summary` gathers recent changes, `batch_log_items` writes a batch of decisions or tasks in one call, and `export_conport_to_markdown` with `import_markdown_to_conport` move data to Markdown files and back. The database schema is updated through Alembic migrations. Every call carries a `workspace_id`, so one server can serve several projects. If no path is given at launch, ConPort finds the project root itself from `.git`, `package.json`, `pyproject.toml` and other markers. The repository contains agent instructions for Roo Code, Cline, Windsurf Cascade and a generic variant: they are pasted into the system prompt so the agent loads and updates memory by itself.
Who it is for. For developers who work with Roo Code, Cline, Windsurf or Cursor and want the agent to keep decisions and progress in a project database.
Good fit when
- The agent keeps losing architectural decisions, and you want them stored with rationale and tags so `search_decisions_fts` can find them
- A file-based Markdown memory bank has grown and searching it became slow and imprecise
- One server has to serve several projects, told apart by `workspace_id`
- You need to link decisions with tasks and see how product context changed through `get_item_history`
- You need a one-off export of the memory bank to Markdown for review, or an import back with `import_markdown_to_conport`
Not a fit when
- The machine has no Python 3.10 or newer and `uv` cannot be installed: the package declares `requires-python >=3.10`
- You need memory across every project and across machines: the database sits in each workspace folder and does not sync by itself
- The agent cannot connect MCP over stdio or you cannot add instructions to the system prompt: without them the agent does not maintain memory on its own
- You want notes as plain Markdown files with wiki links: Basic Memory keeps memory that way
Example request
Log a decision in ConPort: we use Redis for the job queue because it is already in the project, and link it to the task about background email sendingMCP
- Transport
- stdio
- Authentication
- not required
Environment variables
CONPORT_WORKSPACE- Optional workspace path used by auto-detection
Limitations
- The license is Apache-2.0. The manifest carries version 0.3.13 and the classifier Beta.
- The instructions say Python 3.8 or higher, but the manifest requires 3.10 or newer, so follow the manifest.
- Many editors do not expand `${workspaceFolder}` when launching the server. The author advises an absolute path in `--workspace_id`, or leaving it out at launch and passing it in every call. If an IDE passes the literal string `${workspaceFolder}`, ConPort ignores it and finds the root itself.
- Without agent instructions memory does not fill up: the server only answers calls. Windsurf Cascade needs a new session to be told directly to initialize according to custom instructions.
- When updating across versions with a database schema change the author advises reading `v0.2.4_UPDATE_GUIDE.md`: sometimes data has to be moved manually through export and import.
How to disable. Remove the `conport` entry from the MCP settings of the client (in the guide's example this is `mcp_settings.json`). Data stays in the workspace's `context_portal/` folder, which can be deleted by hand. Before deleting you can export memory to Markdown with the `export_conport_to_markdown` tool.
FAQ
Where does ConPort store its data?
In the SQLite database `context_portal/context.db` inside the workspace: it is created on first use. The vector index for semantic search sits in ChromaDB beside it, and Alembic migrations bring the schema to the right version.
How does ConPort differ from a file-based memory bank?
According to the author it replaces older text-file systems with a database where records can be searched, linked and versioned. Instead of reading whole files, the agent calls targeted tools such as `get_decisions` or `search_custom_data_value_fts`.
How do I set the workspace if the editor does not expand the variable?
Pass an absolute path in `--workspace_id`, or leave the flag out and give `workspace_id` in every call. Auto-detection is also on: the server walks up the directories looking for `.git`, `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `pom.xml` or a `context_portal/` folder. The choice is shown by the `get_workspace_detection_info` tool.
Which agent instructions ship in the repository?
The `conport-custom-instructions` folder holds strategies for Roo Code, Cline, Windsurf Cascade and a generic one. There is also the `mem4sprint` set for sprint planning with flat categories and full-text search rules. The file content is copied whole into the system prompt.
Can memory be exported for a human to read?
Yes. `export_conport_to_markdown` writes the data to a folder (default `./conport_export/`) and `import_markdown_to_conport` reads it back. The author also offers this pair as a manual migration path when the database schema changes.
What does stdio mode mean and are there others?
The main deployment mode is stdio: the editor itself starts the `conport-mcp` process and talks to it through standard input and output. The author considers running it in an editor over stdio the most representative test of the server. For development the repository suggests running `uv run` from a local clone.
Discussion
No questions or reviews yet.
Related
MCP serversA local MCP server with five verbs that keeps project decisions across sessions: store, retrieve, supersede and audit diffs.
ContextLattice: a local context layer for agents
ContextLattice
A local memory and context layer: a session's goal, decisions and evidence are gathered into a compact packet an agent reopens
A long-term memory plugin and server for Claude Code and Codex: decisions and handoffs move between sessions and agents
An MCP server that keeps large tool output out of the agent's context window and stores session memory in SQLite
Cortex keeps decisions and project context between Claude Code and Codex sessions in a local database and shows what it recalled
Local memory for agents: decisions from browser chats reach Claude Code, Cursor and Windsurf through MCP
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| Context Portal (this card) | no | not required | 768 | |
| Memory Bank MCP Server | no | not required | 926 | memory files sit in a separate root folder outside the repository, with no database or semantic search |
| MegaMemory | no | not required | 736 | a graph of concepts that the agent describes and records itself, with the model acting as the indexer |
| Basic Memory | no | not required | 4,566 | knowledge lives in plain Markdown files with wiki links that a human edits too |
README in short
The front page explains what ConPort is and lists its features: SQLite per workspace, a vector store, a knowledge graph and Alembic migrations. Next come prerequisites, setup through `uvx` and a developer variant from a clone, a section on agent instructions, workspace auto-detection and a reference of about thirty tools with their arguments. The repository also holds a deep-dive document `conport_mcp_deep_dive.md`, an update guide, a Dockerfile, contribution rules and handler tests.