Connecting MCP to Cognee Cloud
The Cognee MCP server can connect to your Cognee Cloud tenant using the--api-url and --api-token flags, with the API Base URL and API key from your API Keys page. This lets any MCP-compatible client (Claude Desktop, Cursor, VS Code Copilot) work with your cloud-hosted knowledge graph.
How API mode connects to a backend
The MCP server’s--api-url / --api-token options put it in API mode: instead of running pipelines locally, the MCP tools send their requests to the Cognee backend at that URL. API mode works with both self-hosted backends and Cognee Cloud tenants:
- Self-hosted backends authenticate with
Authorization: Bearer <token>by default - Cognee Cloud tenant URLs are detected automatically and authenticate with the
X-Api-Keyheader, plus anX-Tenant-Idheader carrying the tenant ID
tenant-<uuid> label in --api-url and reads the tenant ID from it. A real tenant host looks like https://tenant-0b7c1f2e-3a4d-5e6f-8a9b-0c1d2e3f4a5b.aws.cognee.ai — the your-tenant placeholder used in examples throughout these docs stands in for that label. Copy the API Base URL from your API Keys page verbatim so the label is preserved — an --api-url without it is treated as a self-hosted backend and falls back to Authorization: Bearer <token>, which a Cloud tenant rejects.
URL detection is only the default. --api-auth-scheme x-api-key (or COGNEE_API_AUTH_SCHEME=x-api-key) forces the X-Api-Key header on any backend — which is what a self-hosted instance needs when you authenticate with a server-issued API key rather than a login JWT. --api-auth-scheme bearer forces Authorization: Bearer even on a tenant URL, so avoid setting COGNEE_API_AUTH_SCHEME=bearer in an environment that also talks to Cloud.
The
--serve-url / --serve-api-key flags are a different mechanism: they call cognee.serve() to route SDK operations, and they do not configure the API client the MCP tools use — so a Cloud connection configured only with --serve-url leaves some tools working against local storage. For Cloud connections, use --api-url / --api-token.End-to-end walkthrough
1
Get your API credentials
Open the API Keys page in the Cognee Cloud console. Copy:
- API Base URL — looks like
https://your-tenant.aws.cognee.ai - API Key — a long token used to authenticate requests
2
Start the MCP server
Pass your credentials via CLI flags:The server is ready when you see output like:
3
Add Cognee to your MCP client
Add the server to your client’s MCP configuration. The config file location varies by client — see the integrations section for your specific tool.
4
Verify the connection
Test that memory operations reach your Cloud tenant. In your MCP client, ask:
“Use Cognee to remember: cloud connection test successful”Then retrieve it:
“Use Cognee to recall the cloud connection test”If Cognee returns the stored value, the end-to-end connection is working. You can also confirm the data appeared in the Cognee Cloud UI.
Available tools
Once connected, your MCP client gets the Cognee API v1 memory tools:Other connection options
Use Cognee MCP for local AI memory (standalone)
Use Cognee MCP for local AI memory (standalone)
Run the MCP server in standalone mode (no Cloud connection). The server manages its own local knowledge graph.This is the simplest way to add persistent memory to Cursor, Claude Code, Cline, and other MCP-compatible tools.
Use the Python SDK instead
Use the Python SDK instead
Access Cognee Cloud programmatically using the If you prefer not to use environment variables, pass both values directly:See the Cloud SDK guide for a complete walkthrough.
cognee SDK connected through serve(), which handles authentication and communication with the hosted service.Connect MCP to a self-hosted Cognee backend
Connect MCP to a self-hosted Cognee backend
If you want multiple AI clients to share a single knowledge graph, run a self-hosted Cognee backend and point the MCP server at it using See the MCP Quickstart for full details on this pattern.
API_URL and API_TOKEN: