The difference from a markdown memory file is that this is queryable: filter decisions by tag, full-text search the rationale, link a decision to the progress entry it caused, and read the version history of the context that changed around it.
A database-backed store for project context, one SQLite file per workspace, created automatically. It replaces file-based memory-bank setups with something queryable, and adds vector embeddings so retrieval can be semantic as well as literal.
- Product and active context: `get_product_context` and `update_product_context` for goals, features and architecture; `get_active_context` and `update_active_context` for current focus, recent changes and open issues. Both updates accept a full replacement or a partial patch
- Decisions: `log_decision` with summary, rationale, implementation details and tags; `get_decisions` with tag filters; `search_decisions_fts` for full-text search across every field; `delete_decision_by_id`
- Progress: `log_progress` with status, description and a parent for sub-tasks, plus `get_progress`, `update_progress` and `delete_progress_by_id`
- System patterns: `log_system_pattern`, `get_system_patterns` and `delete_system_pattern_by_id`
- Custom data as a category-and-key store: `log_custom_data`, `get_custom_data`, `delete_custom_data`, with `search_project_glossary_fts` for the glossary category and `search_custom_data_value_fts` across all values, categories and keys
- The graph itself: `link_conport_items` creates a typed relationship between two items and `get_linked_items` walks it
- History and meta: `get_item_history` for versioned product and active context, `get_recent_activity_summary`, and `get_conport_schema` so a client can discover the tool surface
- Portability: `export_conport_to_markdown` and `import_markdown_to_conport`
Python 3.8 or higher, and `uv` strongly recommended. The recommended setup runs the published package with no virtual environment of your own: `uvx --from context-portal-mcp conport-mcp --mode stdio`, with `--log-file` and `--log-level` optional. Every tool takes a `workspace_id` naming the project. Many IDEs do not expand `${workspaceFolder}` when launching MCP servers, so either give an absolute path or omit the launch argument entirely and rely on the per-call value — in that case the database is initialized on the first tool call. Integer-like parameters accept digits as strings as well as numbers. Schema changes are handled by Alembic migrations.