MCP100 verdict
Not currently recommended. Cognee MCP server for persistent knowledge-graph memory and retrieval across AI sessions. Capabilities: Add/manage supported persistent memory; Build/query graph-based knowledge; Retrieve context across sessions/datasets; Operate over local/self-hosted or cloud-backed Cognee deployments
MCP100 Assessment
Editorial verdict
Reviewed October 21, 2026
Task Fit
Mapped
Local files and knowledge
Trust
Status warning
maintenance_source_health; install_supply_chain; advisory_freshness; adoption_evidence_presence; resource_type_requirements
Maintenance
Date unavailable
No dated repository or package update is currently stored.
Popularity
Signals available
Visible usage signals are shown for discovery only, not as proof of safety.
Evidence scope
32.6k shared-repository stars · not MCP-specific
1,288 package downloads · PyPI Stats last_month · Third-party
Repository identity: topoteretes/cognee
Package identity: cognee-mcp · version 0.5.7
Stars observed October 21, 2026 · Downloads observed October 21, 2026
Repository evidence: shared_monorepo. Not MCP-specific/comparable for MCP-server adoption. Correct repo attribution to Shared; dedicated cognee-mcp package is exact.
Package evidence: exact. Exact current MCP implementation/distribution. Correct repo attribution to Shared; dedicated cognee-mcp package is exact.
Publisher activity observed October 21, 2026
Current source snapshot
Source relationship: First-party MCP
Reviewed October 21, 2026
Evidence-backed setup
Choose your MCP client. A client connects to the MCP server; the language model is selected inside that client. Only stored, source-backed configurations are shown.
Transport not recorded
No sufficient client-specific setup evidence has been stored from the publisher or client documentation.
Publisher-documented setup is not the same as MCP100 execution testing. “MCP100 logic checked” means the stored configuration shape was reviewed, not that third-party MCP software was run.
Evidence checked 2026-10-21T00:00:00Z
Type-appropriate, source-backed setup for this mcp server profile.
Loading optional publisher installation details…
No complete evidence-backed client setup steps are currently stored. Optional publisher documentation may provide additional context below.
Capability
Cognee MCP server for persistent knowledge-graph memory and retrieval across AI sessions. Capabilities: Add/manage supported persistent memory; Build/query graph-based knowledge; Retrieve context across sessions/datasets; Operate over local/self-hosted or cloud-backed Cognee deployments
Not measured yet
Estimated token footprint of the MCP tool schemas exposed to the agent.
Reviewed access
Review the exact access boundary before connecting this MCP to accounts, credentials, or sensitive data.
Related reviewed MCPs
Codebase knowledge graph for AI agents — 159 languages, sub-ms queries, 99% fewer tokens.
Choose this instead if
Choose Codebase Memory MCP instead if repository indexing, symbol search, call-path tracing, impact analysis, and architecture queries across many languages.
Recommended after reviewed 2026-09-25 admission dossier: all_current_selected_gates_pass.
Give MCP clients scoped access to a local Obsidian vault.
Choose this instead if
Choose MCPVault for Obsidian instead if obsidian users who want local search and supervised note maintenance.
Give MCP clients scoped access to a local Obsidian vault.
Read and update authorized Coda documents, pages, tables, and rows.
Choose this instead if
Choose coda instead if collaborative document and structured-table workflows in Coda.
Read and update authorized Coda documents, pages, tables, and rows.
github:topoteretes is listed as First-party MCP in MCP100’s current evidence.
Current official resources:
From the publisher README
Original client setup and configuration retained from the publisher documentation.
Publisher-documented clients
These names appear in the publisher's installation documentation. MCP100-verified configurations are shown separately above when available.
git clone https://github.com/topoteretes/cognee.git
cd cognee/cognee-mcp
pip install uv
uv sync --dev --all-extras --reinstall
source .venv/bin/activate
LLM_API_KEY="YOUR_OPENAI_API_KEY"
python src/server.py
python src/server.py --transport sse
python src/server.py --transport http --host 127.0.0.1 --port 8000 --path /mcp
You can do more advanced configurations by creating .env file using our template. To use different LLM providers / database configurations, and for more info check out our documentation.
No API key? If your MCP host grants the
samplingcapability,LLM_PROVIDER="mcp-sampling"delegates completions to the host's own model, so noLLM_API_KEYis needed (embeddings still need a provider). Host support varies — as of early 2026 Claude Code does not yet grant sampling (anthropics/claude-code#1785). See the "MCP sampling" section of the .env template.
Original product, capability, tool, and usage documentation from the MCP publisher. Installation sections appear under Install & Agents.
cognee‑mcp - Run cognee’s memory engine as a Model Context Protocol server
Build memory for Agents and query from any client that speaks MCP – in your terminal or IDE.
--serve-url or COGNEE_SERVICE_URL env var (see Connection Modes)remember, recall, and forget for agent memory workflowsremember toolrecall tool with optional session and search controlscode_searchforget toolPlease refer to our documentation here for further information.
Use code_search for deterministic queries against an indexed code dataset. Select an operation and pass its operation-specific filters in arguments:
{
"operation": "query_facts",
"arguments": {"kinds": ["module", "symbol"], "limit": 100},
"datasets": "sample-code-dataset"
}
Supported operations are query_facts, explore, traverse, find_path, impact_analysis, insights, architecture and delta, plus the navigation operations capabilities, search, neighbors, subgraph, flows, hubs and ask. search and ask take a question in plain words as query.
If you'd rather run cognee-mcp in a container, you have two options:
Build locally
Make sure you are in /cognee root directory and have a fresh .env containing only your LLM_API_KEY (and your chosen settings).
Remove any old image and rebuild:
docker rmi cognee/cognee-mcp:main || true
docker build --no-cache -f cognee-mcp/Dockerfile -t cognee/cognee-mcp:main .
Run it:
# For HTTP transport (recommended for web deployments)
docker run -e TRANSPORT_MODE=http --env-file ./.env -p 8000:8000 --rm -it cognee/cognee-mcp:main
# For SSE transport
docker run -e TRANSPORT_MODE=sse --env-file ./.env -p 8000:8000 --rm -it cognee/cognee-mcp:main
# For stdio transport (default)
docker run -e TRANSPORT_MODE=stdio --env-file ./.env --rm -it cognee/cognee-mcp:main
Installing optional dependencies at runtime:
You can install optional dependencies when running the container by setting the EXTRAS environment variable:
# Install a single optional dependency group at runtime
docker run \
-e TRANSPORT_MODE=http \
-e EXTRAS=aws \
--env-file ./.env \
-p 8000:8000 \
--rm -it cognee/cognee-mcp:main
# Install multiple optional dependency groups at runtime (comma-separated)
docker run \
-e TRANSPORT_MODE=sse \
-e EXTRAS=aws,postgres,neo4j \
--env-file ./.env \
-p 8000:8000 \
--rm -it cognee/cognee-mcp:main
Available optional dependency groups:
aws - S3 storage supportpostgres / postgres-binary - PostgreSQL database supportneo4j - Neo4j graph database supportneptune - AWS Neptune supportturso - Turso vector/graph store supportscraping - Web scraping capabilitieslangchain - LangChain integrationllama-index - LlamaIndex integrationanthropic - Anthropic modelsgroq - Groq modelsmistral - Mistral modelsollama / huggingface - Local model supportdocs - Document processingtracing - OpenTelemetry tracingredis - Redis supportPull from Docker Hub (no build required):
The image is published to Docker Hub on every push to main. If you have not cloned the
repo, create the .env file the run commands expect first — it needs at least your LLM key:
# Pull the prebuilt image
docker pull cognee/cognee-mcp:main
# Create a minimal .env in the current directory (no repo checkout required)
echo 'LLM_API_KEY="YOUR_OPENAI_API_KEY"' > .env
# With HTTP transport (recommended for web deployments)
docker run -e TRANSPORT_MODE=http --env-file ./.env -p 8000:8000 --rm -it cognee/cognee-mcp:main
# With SSE transport
docker run -e TRANSPORT_MODE=sse --env-file ./.env -p 8000:8000 --rm -it cognee/cognee-mcp:main
# With stdio transport (default)
docker run -e TRANSPORT_MODE=stdio --env-file ./.env --rm -it cognee/cognee-mcp:main
With runtime installation of optional dependencies:
# Install optional dependencies from Docker Hub image
docker run \
-e TRANSPORT_MODE=http \
-e EXTRAS=aws,postgres \
--env-file ./.env \
-p 8000:8000 \
--rm -it cognee/cognee-mcp:main
Docker uses environment variables, not command line arguments:
-e TRANSPORT_MODE=http--transport http (won't work)Direct Python usage uses command line arguments:
python src/server.py --transport http-e TRANSPORT_MODE=http (won't work)To connect the MCP Docker container to a Cognee API server running on your host machine:
# Start your Cognee API server on the host
python -m cognee.api.client
# Run MCP container in API mode - localhost is automatically converted!
docker run \
-e TRANSPORT_MODE=sse \
-e API_URL=http://localhost:8000 \
-e API_TOKEN=your_auth_token \
-p 8001:8000 \
--rm -it cognee/cognee-mcp:main
Note: The container will automatically convert localhost to host.docker.internal on Mac/Windows/Docker Desktop. You'll see a message in the logs showing the conversion.
# Or explicitly use host.docker.internal
docker run \
-e TRANSPORT_MODE=sse \
-e API_URL=http://host.docker.internal:8000 \
-e API_TOKEN=your_auth_token \
-p 8001:8000 \
--rm -it cognee/cognee-mcp:main
# Option 1: Use host network (simplest)
docker run \
--network host \
-e TRANSPORT_MODE=sse \
-e API_URL=http://localhost:8000 \
-e API_TOKEN=your_auth_token \
--rm -it cognee/cognee-mcp:main
# Option 2: Use host IP address
# First, get your host IP: ip addr show docker0
docker run \
-e TRANSPORT_MODE=sse \
-e API_URL=http://172.17.0.1:8000 \
-e API_TOKEN=your_auth_token \
-p 8001:8000 \
--rm -it cognee/cognee-mcp:main
Environment variables for API mode:
API_URL: URL of the running Cognee API serverAPI_TOKEN: Authentication token (optional, required if API has authentication enabled)Note: When running in API mode:
After starting your Cognee MCP server with Docker, you need to configure your MCP client to connect to it.
⚠️ Host/Origin protection (why you might get HTTP 421 or 403)
Both the http and sse transports validate the
HostandOriginheaders to block DNS-rebinding attacks, on every bind address including loopback — rebinding targets loopback services specifically, so127.0.0.1is not a mitigation.
- A
Hostthe server does not recognise returns421 Misdirected Request- An
Originit does not recognise returns403 ForbiddenWhen you bind a non-loopback address (
--host 0.0.0.0, which is what the Docker entrypoint does), onlylocalhost/127.0.0.1/[::1]are accepted by default, so reaching the server by LAN IP or a custom hostname returns 421 — the guard working, not a bug.Allow specific hosts (the
:*port glob is required):-e MCP_ALLOWED_HOSTS="192.168.1.50:*,myserver.local:*"Or turn the guard off entirely (only on a trusted network):
-e MCP_DISABLE_DNS_REBINDING_PROTECTION=trueImplementation note. FastMCP installs this guard on its streamable-http app only —
create_sse_app()accepts no such option, so the allow-lists were silently dropped for SSE. cognee-mcp mounts the same middleware on the SSE app itself, with the same allow-lists, so both transports behave identically.
Start the server with SSE transport:
docker run -e TRANSPORT_MODE=sse --env-file ./.env -p 8000:8000 --rm -it cognee/cognee-mcp:main
Configure your MCP client:
claude mcp add cognee-sse -t sse http://localhost:8000/sse
Verify the connection:
claude mcp list
You should see your server connected:
Checking MCP server health...
cognee-sse: http://localhost:8000/sse (SSE) - ✓ Connected
Claude (~/.claude.json)
{
"mcpServers": {
"cognee": {
"type": "sse",
"url": "http://localhost:8000/sse"
}
}
}
Cursor (~/.cursor/mcp.json)
{
"mcpServers": {
"cognee-sse": {
"url": "http://localhost:8000/sse"
}
}
}
Start the server with HTTP transport:
docker run -e TRANSPORT_MODE=http --env-file ./.env -p 8000:8000 --rm -it cognee/cognee-mcp:main
Configure your MCP client:
claude mcp add cognee-http -t http http://localhost:8000/mcp
Verify the connection:
claude mcp list
You should see your server connected:
Checking MCP server health...
cognee-http: http://localhost:8000/mcp (HTTP) - ✓ Connected
Claude (~/.claude.json)
{
"mcpServers": {
"cognee": {
"type": "http",
"url": "http://localhost:8000/mcp"
}
}
}
Cursor (~/.cursor/mcp.json)
{
"mcpServers": {
"cognee-http": {
"url": "http://localhost:8000/mcp"
}
}
}
You can configure both transports simultaneously for testing:
{
"mcpServers": {
"cognee-sse": {
"type": "sse",
"url": "http://localhost:8000/sse"
},
"cognee-http": {
"type": "http",
"url": "http://localhost:8000/mcp"
}
}
}
Note: Only enable the server you're actually running to avoid connection errors.
The MCP server supports three connection modes:
The MCP server directly imports and uses the cognee library with local databases (SQLite, LanceDB, Ladybug). This is the default mode with full feature support.
Connect to Cognee Cloud or a remote Cognee instance. The server calls cognee.serve() at startup, and all SDK operations transparently route to the cloud. No local databases needed.
Via CLI flags:
python src/server.py --serve-url https://your-instance.cognee.ai --serve-api-key ck_...
Via environment variables (zero-config):
export COGNEE_SERVICE_URL="https://your-instance.cognee.ai"
export COGNEE_API_KEY="ck_..."
python src/server.py
Cloud Mode with Docker:
docker run \
-e TRANSPORT_MODE=sse \
-e COGNEE_SERVICE_URL=https://your-instance.cognee.ai \
-e COGNEE_API_KEY=ck_... \
-p 8000:8000 \
--rm -it cognee/cognee-mcp:main
Cloud Mode arguments / environment variables:
--serve-url / COGNEE_SERVICE_URL: Cognee Cloud or remote instance URL--serve-api-key / COGNEE_API_KEY: API key for the instanceDatabase migrations are automatically skipped in Cloud mode.
The MCP server connects to an already running Cognee FastAPI server via HTTP requests. This is useful when:
Starting the MCP server in API mode:
# Start your Cognee FastAPI server first (default port 8000)
cd /path/to/cognee
python -m cognee.api.client
# Then start the MCP server in API mode
cd cognee-mcp
python src/server.py --api-url http://localhost:8000 --api-token YOUR_AUTH_TOKEN
API Mode with different transports:
# With SSE transport
python src/server.py --transport sse --api-url http://localhost:8000 --api-token YOUR_TOKEN
# With HTTP transport
python src/server.py --transport http --api-url http://localhost:8000 --api-token YOUR_TOKEN
API Mode with Docker:
# On Mac/Windows (use host.docker.internal to access host)
docker run \
-e TRANSPORT_MODE=sse \
-e API_URL=http://host.docker.internal:8000 \
-e API_TOKEN=YOUR_TOKEN \
-p 8001:8000 \
--rm -it cognee/cognee-mcp:main
# On Linux (use host network)
docker run \
--network host \
-e TRANSPORT_MODE=sse \
-e API_URL=http://localhost:8000 \
-e API_TOKEN=YOUR_TOKEN \
--rm -it cognee/cognee-mcp:main
Command-line arguments for API mode:
--api-url: Base URL of the running Cognee FastAPI server (e.g., http://localhost:8000)--api-token: Authentication token for the API (optional, required if API has authentication enabled)Docker environment variables for API mode:
API_URL: Base URL of the running Cognee FastAPI serverAPI_TOKEN: Authentication token (optional, required if API has authentication enabled)API Mode behavior:
The MCP server intentionally exposes only the memory API: remember, recall, and forget (plus the cognify_status progress check).
In API mode these tools call the Cognee API server endpoints directly. Operational helpers such as
cognify, search, list_data, delete, prune, improve, and document retrieval helpers are
kept internal and are not exposed as MCP tools.
The MCP server exposes its functionality through tools. Call them from any MCP client (Cursor, Claude Desktop, Cline, Roo and more).
The MCP server exposes four tools (three memory tools pinned in tools/list, plus cognify_status):
data for text, or filename + content_base64 to ingest an uploaded file (up to 10 MB). With session_id: fast session cache (text only). Without session_id: permanent graph memorysession_id is provided, then falls through to the permanent graphdata_id (paired with its dataset_id, both shown by recall with include_references=True), or delete all owned memory with everything=Trueremember(background=True). Unadvertised by default; discoverable via search_tools and callable by namerecall (the MCP memory-search tool) starts every successful response with a
summary, followed by the same result body as before:
3 memories found (2 from sessions, 1 from project docs)
[session] ...
The count is the number of returned memory entries, not top_k, underlying
chunks used to synthesize an answer, or system status messages. Source and dataset
hints use metadata already present in the returned entries; no recency lookup or
extra LLM call is made.
Empty results distinguish an empty memory graph, indexing in progress, indexing
failure, and no match. When available, progress is displayed as, for example,
still indexing — 12/40 items processed, retry shortly. These are data items,
not an inferred chunk count. A graph with no recorded indexing run is reported
as not yet indexed. If the status check fails or exceeds its two-second budget,
the summary explicitly says memory status is unavailable. Successful hits do
not trigger status checks.
The MCP content remains a single TextContent block. Text consumers can separate
line one from the unchanged body with text.partition("\n"). Machine consumers
can read content[0]._meta["cognee/memory"], containing count and state.
state is one of four values, one per action a caller can take:
| state | meaning |
|---|---|
found | memory contributed; count is how many entries |
indexing | ingestion is still running — retry shortly |
build_failed | ingestion failed — check cognify_status |
none | nothing to return |
indexing additionally carries completed/total when the pipeline reports
them. Tool errors retain their existing Error: response.
COGNEE_MCP_TOOL_MODE)Advertising every tool up front costs agent context and hurts tool-selection accuracy, so by default the server pins a small set in tools/list and makes the rest discoverable through FastMCP's built-in search_tools. Unadvertised tools stay callable by name.
COGNEE_MCP_TOOL_MODE=default # pinned: remember, recall, forget
COGNEE_MCP_TOOL_MODE=minimal # pinned: remember, recall, forget
COGNEE_MCP_TOOL_MODE=all # no search transform; advertise every tool
Also settable per-process with --tool-mode. In default/minimal an agent calls search_tools(query=...) to find a tool and either calls it by name or goes through the call_tool proxy. Tiers are declared per tool via @registry.tool(tags={...}) in src/server.py, so the pinned set is derived from the decorators rather than a separate list.
search_tools returns up to TOOL_SEARCH_MAX_RESULTS (10) tools, sized for a catalog that will grow. The window only costs context on turns that actually call search; tools/list stays constant either way. See tests/test_tool_search_benchmark.py for the recall sweep behind the number.
Search works well on natural-language queries. Every phrasing below returns its target ranked first (covered by tests/test_tool_search.py):
| query | returns |
|---|---|
| "is my background ingestion finished?" | cognify_status |
| "check the progress of a pipeline job" | cognify_status |
The one thing to know when adding a tool: matching is purely lexical. FastMCP's BM25 tokenizer does no stemming and drops tools that score zero, so a query shares no credit with a word it doesn't literally contain. Multi-word queries paper over this (they usually contain some matching token), which is why the table above passes, but terse queries won't.
So: write descriptions in the words an agent would use, including both singular and plural. Recall is bounded by vocabulary, not by TOOL_SEARCH_MAX_RESULTS. If lexical matching ever stops being enough, BaseSearchTransform leaves _search() abstract — a semantic ranker over cognee's own embeddings can be dropped in without touching the rest of the plumbing.
By default, each MCP client gets its own auto-named dataset (e.g. Cursor → cursor_vscode_memory, Claude Code → claude_code_memory) so different agents don't share memory unintentionally. The dataset is created on demand the first time a client writes to it.
remember and cognify_status route to the agent-scoped dataset when dataset_name is omitted (the internal cognify/improve helpers, which are not exposed as tools, do the same). Pass dataset_name explicitly to override (e.g. dataset_name="main_dataset" still works).
To disable agent scoping and have all clients share main_dataset as the default, set in .env:
COGNEE_MCP_AGENT_SCOPED=false
When disabled, no per-client datasets are autocreated.
ENABLE_BACKEND_ACCESS_CONTROL)Agent scoping decides which dataset name a tool defaults to. Whether two datasets are actually isolated at the storage layer is governed by cognee's ENABLE_BACKEND_ACCESS_CONTROL flag:
true (default) — each (user, dataset) pair gets its own per-dataset Kuzu + LanceDB under .cognee_system/databases/<dataset_uuid>/, and search is strictly per-dataset.false — all datasets share one Kuzu graph DB and one LanceDB. The dataset filter is honored for top-level data points, but GRAPH_COMPLETION traversal can pull connected nodes from any dataset. Use for single-user local dev; also disables the API auth requirement unless REQUIRE_AUTHENTICATION=true is set explicitly.Switching modes wipes nothing automatically — but data does not migrate. Data ingested in one mode lives at a different on-disk path than the other and won't be visible after the flip. Clean-slate when changing the flag:
# Stop server, then:
DATA_ROOT="/absolute/path/to/data-root"
rm -rf "$DATA_ROOT/.cognee_system" "$DATA_ROOT/.data_storage"
# Edit .env to flip ENABLE_BACKEND_ACCESS_CONTROL, restart, re-cognify.
(Set DATA_ROOT to whatever you used for DATA_ROOT_DIRECTORY / SYSTEM_ROOT_DIRECTORY, or your cognee install dir if you didn't set those.)
Examples:
# Store permanent memory
remember(data="Cognee MCP now exposes a focused memory API.", dataset_name="main_dataset")
# Store permanent memory without the automatic improve stage (add + cognify still run)
remember(data="A new fact", dataset_name="main_dataset", self_improvement=False)
# The opt-out also applies to file uploads and background=True ingestion
remember(data="A new fact", self_improvement=False, background=True)
# Store session memory without a background graph bridge in direct mode
remember(data="Temporary working note", session_id="agent-session-1", self_improvement=False)
# Recall from memory
recall(query="What changed in the MCP server?", session_id="agent-session-1")
# Delete one dataset
forget(dataset="main_dataset")
# Forget one item: recall it with references, then forget it by its ids
recall(query="What is the vault recovery phrase?", include_references=True)
# -> [graph] amber-falcon-42
#
# Evidence:
# - chunk 1 of document text_<hash> (data_id: <uuid>, chunk_id: <uuid>): "The vault recovery phrase is ..."
# dataset: main_dataset (dataset_id=<uuid>)
forget(data_id="<uuid>", dataset_id="<uuid>")
include_references=True shows the ids forget needs; without it the output is
unchanged. The default answer cites its sources in an Evidence: block (best
match first) and gets a dataset: line. CHUNKS, SUMMARIES, RAG and
graph-completion hits get refs: data_id=..., dataset_id=..., document=...
lines instead (at most five per hit, best match first). A chunk hit names the
one item its text came from, while a graph-completion answer lists every item
in its context, so use the default type or search_type="CHUNKS" to find one
fact. Session hits are not stored data and carry no ids. With backend access
control off, ids are only shown when recall is scoped to a single dataset.
self_improvement defaults to True; only an explicit False is forwarded, so
True leaves the core default in charge. In permanent mode, False disables
automatic improvement without skipping ingestion or graph building.
In direct session mode, it disables the automatic session-to-graph bridge while
still storing the session entry. In API session mode, MCP uses typed QA entries,
which stay in the session cache for all flag values; the flag does not enable a
graph bridge there. It does not control separately requested skill improvement.
Pass ontology_key to remember to ground permanent-memory extraction with one
or more previously uploaded OWL ontologies:
remember(data="Alice works at Acme.", dataset_name="workspace_a", ontology_key="workspace_a_v2")
remember(
data="Acme develops software.",
ontology_key=["organizations", "software"],
background=True,
)
In API mode, upload the ontologies first through POST /api/v1/ontologies using
the same authenticated user as the MCP server. Keys are sent as repeated
ontology_key form fields. In local mode, keys resolve through OntologyService
in the default user's local ontology store; remote uploads are not copied locally.
Unknown or inaccessible keys fail the write. Background failures are reported by
cognify_status.
Omitting ontology_key (or passing an empty list) preserves the configured
server ontology, including ONTOLOGY_FILE_PATH. Ontology selection is only for
permanent writes: combining a nonempty key with session_id returns an error
because session-cache writes do not perform extraction.
Use the fastmcp CLI, not mcp. Since the FastMCP 3 migration this server is a
standalone fastmcp.FastMCP instance, which the mcp CLI does not recognise —
mcp dev src/server.py fails with "Ignoring object 'src/server.py:mcp' as it's not a
valid server object".
Inspect the server without launching anything (fast sanity check — name, version, tool count):
uv run fastmcp inspect src/server.py:mcp
Run it against the MCP Inspector UI:
uv run fastmcp dev src/server.py:mcp
Open the inspector with a longer timeout — cognee's first call can be slow while the databases initialise:
http://localhost:5173?timeout=120000
To apply new changes while developing cognee:
uv sync --group dev --reinstalluv run fastmcp dev src/server.py:mcpThe
:mcpsuffix names the server object in the file. Without it the CLI has to guess, and the guess is not reliable across FastMCP versions.
In order to use local cognee:
Uncomment the following line in the cognee-mcp pyproject.toml file and set the cognee root path.
#"cognee[postgres-binary,docs,neo4j] @ file:/path/to/your/cognee"
Replace /path/to/your/cognee with the absolute path to your cognee checkout, and
comment out the released "cognee[...]>=1.5.0,<2.0.0" line directly below it —
otherwise both requirements apply and uv resolves the published package instead.
Install dependencies with uv in the mcp folder
uv sync --reinstall
Re-run this after every change to the local cognee checkout.
Note: editing that line modifies the tracked
pyproject.tomland rewritesuv.lockwith a machine-local absolute path. Revert both before committing —git checkout -- pyproject.toml uv.lock— or the path leaks into the repo.
We are committed to making open source an enjoyable and respectful experience for our community. See CODE_OF_CONDUCT for more information.